Eclipse Community Forums - RDF feed
https://www.eclipse.org/forums/
Eclipse Community Forums[CDO][0.8.0] IStoreReader API
https://www.eclipse.org/forums/index.php/mv/msg/29003/94161/#msg_94161
I have the following problem.
I use CDO to access my database.
Objects can be modify through that API. In this case the CDORevisionResolver
has always the latest version.
In my context, objects can be modified through another application that
doesn't use CDO (native one).
The problem is when my objects are in my cache (CDORevisionResolver - server
side) it doesn't check with StoreReader if the version he got its the
latest one.
I think it should.
So I will like to add the following :
/** If it hit the cache... but need to change the values if not good anymore
**/
void IStoreReader.verifyRevision(CDORevision )
// In these calls
TimeLine.getRevision()
TimeLine.getRevision(long timestamp)
>> We can call RevisionManager.verifyRevision in the case where we did found
>> a CDORevision in the cache.
RevisionManager.verifyRevision(CDORevision)
RevisionManager.verifyRevision(CDORevision, long timestamp)
>> We can call IstoreReader.verifyRevision(CDORevision )
If you agree I cann add a feature request in Bugzilla]]>Simon Mc Duff2007-08-25T16:34:24-00:00Re: [CDO][0.8.0] IStoreReader API
https://www.eclipse.org/forums/index.php/mv/msg/29003/94183/#msg_94183
Originally posted by: stepper.sympedia.de
This is a multi-part message in MIME format.
--------------050805040709030103000906
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Hi Simon,
Yes, that's a very good idea. Please open a feature request.
I don't think that we'll need the verify call in the timeStamped methods
because they are only used to load historical revisions and these do
never change once committed.
Of course a non-CDO client could change them nevertheless but I think we
should not encourage to do so.
BTW you'll notice that I added a new IRepositoryElement: ITypeManager.
The implementation of it will manage a persistent object type cache if
your IStore returns false on hasEfficientTypeLookup().
The file based cache is pretty simple but scalable and fast. When you
drop a test db you'll have to delete the state folder of the repository!
Please tell me if that works well with your XML store.
Cheers
/Eike
Simon McDuff schrieb:
> Hi Eike,
>
>
> I have the following problem.
>
> I use CDO to access my database.
> Objects can be modify through that API. In this case the CDORevisionResolver
> has always the latest version.
> In my context, objects can be modified through another application that
> doesn't use CDO (native one).
> The problem is when my objects are in my cache (CDORevisionResolver - server
> side) it doesn't check with StoreReader if the version he got its the
> latest one.
> I think it should.
>
> So I will like to add the following :
>
> /** If it hit the cache... but need to change the values if not good anymore
> **/
> void IStoreReader.verifyRevision(CDORevision )
>
>
> // In these calls
> TimeLine.getRevision()
> TimeLine.getRevision(long timestamp)
>
>>> We can call RevisionManager.verifyRevision in the case where we did found
>>> a CDORevision in the cache.
>>>
>
>
> RevisionManager.verifyRevision(CDORevision)
> RevisionManager.verifyRevision(CDORevision, long timestamp)
>
>>> We can call IstoreReader.verifyRevision(CDORevision )
>>>
>
> If you agree I cann add a feature request in Bugzilla
>
>
>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Simon,<br>
<br>
Yes, that's a very good idea. Please open a feature request.<br>
<br>
I don't think that we'll need the verify call in the timeStamped
methods because they are only used to load historical revisions and
these do never change once committed.<br>
Of course a non-CDO client could change them nevertheless but I think
we should not encourage to do so.<br>
<br>
BTW you'll notice that I added a new IRepositoryElement: ITypeManager.<br>
The implementation of it will manage a persistent object type cache if
your IStore returns false on hasEfficientTypeLookup().<br>
The file based cache is pretty simple but scalable and fast. When you
drop a test db you'll have to delete the state folder of the repository!<br>
Please tell me if that works well with your XML store.<br>
<br>
Cheers<br>
/Eike<br>
<br>
<br>
Simon McDuff schrieb:
<blockquote cite="mid:faplmi$ve2$1@build.eclipse.org" type="cite">
<pre wrap="">Hi Eike,
I have the following problem.
I use CDO to access my database.
Objects can be modify through that API. In this case the CDORevisionResolver
has always the latest version.
In my context, objects can be modified through another application that
doesn't use CDO (native one).
The problem is when my objects are in my cache (CDORevisionResolver - server
side) it doesn't check with StoreReader if the version he got its the
latest one.
I think it should.
So I will like to add the following :
/** If it hit the cache... but need to change the values if not good anymore
**/
void IStoreReader.verifyRevision(CDORevision )
// In these calls
TimeLine.getRevision()
TimeLine.getRevision(long timestamp)
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">We can call RevisionManager.verifyRevision in the case where we did found
a CDORevision in the cache.
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->
RevisionManager.verifyRevision(CDORevision)
RevisionManager.verifyRevision(CDORevision, long timestamp)
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">We can call IstoreReader.verifyRevision(CDORevision )
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->
If you agree I cann add a feature request in Bugzilla
Yes, that's a very good idea. Please open a feature request.
I don't think that we'll need the verify call in the timeStamped methods
because they are only used to load historical revisions and these do
never change once committed.
Of course a non-CDO client could change them nevertheless but I think we
should not encourage to do so.
BTW you'll notice that I added a new IRepositoryElement: ITypeManager.
The implementation of it will manage a persistent object type cache if
your IStore returns false on hasEfficientTypeLookup().
The file based cache is pretty simple but scalable and fast. When you
drop a test db you'll have to delete the state folder of the repository!
Please tell me if that works well with your XML store.
Cheers
/Eike
Simon McDuff schrieb:
> Hi Eike,
>
>
> I have the following problem.
>
> I use CDO to access my database.
> Objects can be modify through that API. In this case the CDORevisionResolver
> has always the latest version.
> In my context, objects can be modified through another application that
> doesn't use CDO (native one).
> The problem is when my objects are in my cache (CDORevisionResolver - server
> side) it doesn't check with StoreReader if the version he got its the
> latest one.
> I think it should.
>
> So I will like to add the following :
>
> /** If it hit the cache... but need to change the values if not good anymore
> **/
> void IStoreReader.verifyRevision(CDORevision )
>
>
> // In these calls
> TimeLine.getRevision()
> TimeLine.getRevision(long timestamp)
>
>>> We can call RevisionManager.verifyRevision in the case where we did found
>>> a CDORevision in the cache.
>>>
>
>
> RevisionManager.verifyRevision(CDORevision)
> RevisionManager.verifyRevision(CDORevision, long timestamp)
>
>>> We can call IstoreReader.verifyRevision(CDORevision )
>>>
>
> If you agree I cann add a feature request in Bugzilla
>
>
>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Simon,<br>
<br>
Yes, that's a very good idea. Please open a feature request.<br>
<br>
I don't think that we'll need the verify call in the timeStamped
methods because they are only used to load historical revisions and
these do never change once committed.<br>
Of course a non-CDO client could change them nevertheless but I think
we should not encourage to do so.<br>
<br>
BTW you'll notice that I added a new IRepositoryElement: ITypeManager.<br>
The implementation of it will manage a persistent object type cache if
your IStore returns false on hasEfficientTypeLookup().<br>
The file based cache is pretty simple but scalable and fast. When you
drop a test db you'll have to delete the state folder of the repository!<br>
Please tell me if that works well with your XML store.<br>
<br>
Cheers<br>
/Eike<br>
<br>
<br>
Simon McDuff schrieb:
<blockquote cite="mid:faplmi$ve2$1@build.eclipse.org" type="cite">
<pre wrap="">Hi Eike,
I have the following problem.
I use CDO to access my database.
Objects can be modify through that API. In this case the CDORevisionResolver
has always the latest version.
In my context, objects can be modified through another application that
doesn't use CDO (native one).
The problem is when my objects are in my cache (CDORevisionResolver - server
side) it doesn't check with StoreReader if the version he got its the
latest one.
I think it should.
So I will like to add the following :
/** If it hit the cache... but need to change the values if not good anymore
**/
void IStoreReader.verifyRevision(CDORevision )
// In these calls
TimeLine.getRevision()
TimeLine.getRevision(long timestamp)
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">We can call RevisionManager.verifyRevision in the case where we did found
a CDORevision in the cache.
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->
RevisionManager.verifyRevision(CDORevision)
RevisionManager.verifyRevision(CDORevision, long timestamp)
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">We can call IstoreReader.verifyRevision(CDORevision )
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->
If you agree I cann add a feature request in Bugzilla
</pre>
</blockquote>
</body>
</html>
--------------050805040709030103000906--]]>Eike Stepper2007-08-25T18:04:03-00:00Re: [CDO][0.8.0] IStoreReader API
https://www.eclipse.org/forums/index.php/mv/msg/29003/94219/#msg_94219
Originally posted by: stepper.sympedia.de
This is a multi-part message in MIME format.
--------------000403070204090403050201
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Eike Stepper schrieb:
> Hi Simon,
>
> Yes, that's a very good idea. Please open a feature request.
>
> I don't think that we'll need the verify call in the timeStamped
> methods because they are only used to load historical revisions and
> these do never change once committed.
> Of course a non-CDO client could change them nevertheless but I think
> we should not encourage to do so.
>
> BTW you'll notice that I added a new IRepositoryElement: ITypeManager.
> The implementation of it will manage a persistent object type cache if
> your IStore returns false on hasEfficientTypeLookup().
> The file based cache is pretty simple but scalable and fast. When you
> drop a test db you'll have to delete the state folder of the repository!
> Please tell me if that works well with your XML store.
>
> Cheers
> /Eike
>
>
> Simon McDuff schrieb:
>> Hi Eike,
>>
>>
>> I have the following problem.
>>
>> I use CDO to access my database.
>> Objects can be modify through that API. In this case the CDORevisionResolver
>> has always the latest version.
>> In my context, objects can be modified through another application that
>> doesn't use CDO (native one).
>> The problem is when my objects are in my cache (CDORevisionResolver - server
>> side) it doesn't check with StoreReader if the version he got its the
>> latest one.
>> I think it should.
>>
>> So I will like to add the following :
>>
>> /** If it hit the cache... but need to change the values if not good anymore
>> **/
>> void IStoreReader.verifyRevision(CDORevision )
>>
>>
>> // In these calls
>> TimeLine.getRevision()
>> TimeLine.getRevision(long timestamp)
>>
>>>> We can call RevisionManager.verifyRevision in the case where we did found
>>>> a CDORevision in the cache.
>>>>
>>
>>
>> RevisionManager.verifyRevision(CDORevision)
>> RevisionManager.verifyRevision(CDORevision, long timestamp)
>>
>>>> We can call IstoreReader.verifyRevision(CDORevision )
>>>>
>>
>> If you agree I cann add a feature request in Bugzilla
>>
>>
>>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Bugzilla filed: <a class="moz-txt-link-freetext" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=201170">https://bugs.eclipse.org/bugs/show_bug.cgi?id=201170</a><br>
<br>
<br>
Eike Stepper schrieb:
<blockquote cite="mid:fapqu4$pdh$1@build.eclipse.org" type="cite">
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
Hi Simon,<br>
<br>
Yes, that's a very good idea. Please open a feature request.<br>
<br>
I don't think that we'll need the verify call in the timeStamped
methods because they are only used to load historical revisions and
these do never change once committed.<br>
Of course a non-CDO client could change them nevertheless but I think
we should not encourage to do so.<br>
<br>
BTW you'll notice that I added a new IRepositoryElement: ITypeManager.<br>
The implementation of it will manage a persistent object type cache if
your IStore returns false on hasEfficientTypeLookup().<br>
The file based cache is pretty simple but scalable and fast. When you
drop a test db you'll have to delete the state folder of the repository!<br>
Please tell me if that works well with your XML store.<br>
<br>
Cheers<br>
/Eike<br>
<br>
<br>
Simon McDuff schrieb:
<blockquote cite="mid:faplmi$ve2$1@build.eclipse.org" type="cite">
<pre wrap="">Hi Eike,
I have the following problem.
I use CDO to access my database.
Objects can be modify through that API. In this case the CDORevisionResolver
has always the latest version.
In my context, objects can be modified through another application that
doesn't use CDO (native one).
The problem is when my objects are in my cache (CDORevisionResolver - server
side) it doesn't check with StoreReader if the version he got its the
latest one.
I think it should.
So I will like to add the following :
/** If it hit the cache... but need to change the values if not good anymore
**/
void IStoreReader.verifyRevision(CDORevision )
// In these calls
TimeLine.getRevision()
TimeLine.getRevision(long timestamp)
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">We can call RevisionManager.verifyRevision in the case where we did found
a CDORevision in the cache.
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->
RevisionManager.verifyRevision(CDORevision)
RevisionManager.verifyRevision(CDORevision, long timestamp)
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">We can call IstoreReader.verifyRevision(CDORevision )
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->
If you agree I cann add a feature request in Bugzilla
Eike Stepper schrieb:
> Hi Simon,
>
> Yes, that's a very good idea. Please open a feature request.
>
> I don't think that we'll need the verify call in the timeStamped
> methods because they are only used to load historical revisions and
> these do never change once committed.
> Of course a non-CDO client could change them nevertheless but I think
> we should not encourage to do so.
>
> BTW you'll notice that I added a new IRepositoryElement: ITypeManager.
> The implementation of it will manage a persistent object type cache if
> your IStore returns false on hasEfficientTypeLookup().
> The file based cache is pretty simple but scalable and fast. When you
> drop a test db you'll have to delete the state folder of the repository!
> Please tell me if that works well with your XML store.
>
> Cheers
> /Eike
>
>
> Simon McDuff schrieb:
>> Hi Eike,
>>
>>
>> I have the following problem.
>>
>> I use CDO to access my database.
>> Objects can be modify through that API. In this case the CDORevisionResolver
>> has always the latest version.
>> In my context, objects can be modified through another application that
>> doesn't use CDO (native one).
>> The problem is when my objects are in my cache (CDORevisionResolver - server
>> side) it doesn't check with StoreReader if the version he got its the
>> latest one.
>> I think it should.
>>
>> So I will like to add the following :
>>
>> /** If it hit the cache... but need to change the values if not good anymore
>> **/
>> void IStoreReader.verifyRevision(CDORevision )
>>
>>
>> // In these calls
>> TimeLine.getRevision()
>> TimeLine.getRevision(long timestamp)
>>
>>>> We can call RevisionManager.verifyRevision in the case where we did found
>>>> a CDORevision in the cache.
>>>>
>>
>>
>> RevisionManager.verifyRevision(CDORevision)
>> RevisionManager.verifyRevision(CDORevision, long timestamp)
>>
>>>> We can call IstoreReader.verifyRevision(CDORevision )
>>>>
>>
>> If you agree I cann add a feature request in Bugzilla
>>
>>
>>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Bugzilla filed: <a class="moz-txt-link-freetext" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=201170">https://bugs.eclipse.org/bugs/show_bug.cgi?id=201170</a><br>
<br>
<br>
Eike Stepper schrieb:
<blockquote cite="mid:fapqu4$pdh$1@build.eclipse.org" type="cite">
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
Hi Simon,<br>
<br>
Yes, that's a very good idea. Please open a feature request.<br>
<br>
I don't think that we'll need the verify call in the timeStamped
methods because they are only used to load historical revisions and
these do never change once committed.<br>
Of course a non-CDO client could change them nevertheless but I think
we should not encourage to do so.<br>
<br>
BTW you'll notice that I added a new IRepositoryElement: ITypeManager.<br>
The implementation of it will manage a persistent object type cache if
your IStore returns false on hasEfficientTypeLookup().<br>
The file based cache is pretty simple but scalable and fast. When you
drop a test db you'll have to delete the state folder of the repository!<br>
Please tell me if that works well with your XML store.<br>
<br>
Cheers<br>
/Eike<br>
<br>
<br>
Simon McDuff schrieb:
<blockquote cite="mid:faplmi$ve2$1@build.eclipse.org" type="cite">
<pre wrap="">Hi Eike,
I have the following problem.
I use CDO to access my database.
Objects can be modify through that API. In this case the CDORevisionResolver
has always the latest version.
In my context, objects can be modified through another application that
doesn't use CDO (native one).
The problem is when my objects are in my cache (CDORevisionResolver - server
side) it doesn't check with StoreReader if the version he got its the
latest one.
I think it should.
So I will like to add the following :
/** If it hit the cache... but need to change the values if not good anymore
**/
void IStoreReader.verifyRevision(CDORevision )
// In these calls
TimeLine.getRevision()
TimeLine.getRevision(long timestamp)
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">We can call RevisionManager.verifyRevision in the case where we did found
a CDORevision in the cache.
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->
RevisionManager.verifyRevision(CDORevision)
RevisionManager.verifyRevision(CDORevision, long timestamp)
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">We can call IstoreReader.verifyRevision(CDORevision )
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->
If you agree I cann add a feature request in Bugzilla