Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc)  » [CDO][0.8.0] IStoreReader API
[CDO][0.8.0] IStoreReader API [message #94161] Sat, 25 August 2007 16:34 Go to next message
Simon Mc Duff is currently offline Simon Mc DuffFriend
Messages: 596
Registered: July 2009
Senior Member
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
Re: [CDO][0.8.0] IStoreReader API [message #94183 is a reply to message #94161] Sat, 25 August 2007 18:04 Go to previous messageGo to next message
Eclipse UserFriend
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
>
>
>

--------------050805040709030103000906
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit

<!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--
Re: [CDO][0.8.0] IStoreReader API [message #94219 is a reply to message #94183] Sun, 26 August 2007 04:45 Go to previous message
Eclipse UserFriend
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

Bugzilla filed: https://bugs.eclipse.org/bugs/show_bug.cgi?id=201170


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
>>
>>
>>

--------------000403070204090403050201
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit

<!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


</pre>
</blockquote>
</blockquote>
</body>
</html>

--------------000403070204090403050201--
Re: [CDO][0.8.0] IStoreReader API [message #609523 is a reply to message #94161] Sat, 25 August 2007 18:04 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6634
Registered: July 2009
Senior Member
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
>
>
>

--------------050805040709030103000906
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit

<!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--


Re: [CDO][0.8.0] IStoreReader API [message #609527 is a reply to message #94183] Sun, 26 August 2007 04:45 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6634
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------000403070204090403050201
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

Bugzilla filed: https://bugs.eclipse.org/bugs/show_bug.cgi?id=201170


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
>>
>>
>>

--------------000403070204090403050201
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit

<!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


</pre>
</blockquote>
</blockquote>
</body>
</html>

--------------000403070204090403050201--


Previous Topic:[CDO][0.8.0] EAnnotation
Next Topic:Valid Fetch Types
Goto Forum:
  


Current Time: Mon Sep 26 13:01:20 GMT 2022

Powered by FUDForum. Page generated in 0.01693 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top