Home » Modeling » EMF » [CDO] revisions, Hibernate store.
|
| Re: [CDO] revisions, Hibernate store. [message #713810 is a reply to message #713449] |
Tue, 09 August 2011 06:00   |
|
Am 08.08.2011 15:28, schrieb Christophe Bouhier:
> Hi,
>
> I have a requirements to keep revision of Objects for some specific objects only.
CDO, irrespective of the configured IStore implementation or the supported repository mode (non-auditing, auditing,
branching), does always use CDORevisions to capture, transfer and store the current state of your objects. So I guess
what you really mean is that you don't to use auditing for all objects but for some of them. That's not supported by CDO
because then the framework could not guarantee the consistency of the object graph at all times.
> I understand, that the revisions feature is not supported with Hibernatestore. Is this confirmed?
Confirmed.
> I do see, the version number of my objects being incremented on editing. Is this correct behavior?
Yes, definitely. I already mentioned that CDORevisions are always used and they always carry a version number that
reflects the number of commits that changed the respective object since its initial creation. This version number is
also used to detect conflicting (possibly concurrent) commits in the server.
>
> Just in case I will be able to use revisions (Perhaps a DB store which works with Postgres) , can anyone please point
> out how to use the API CDORevision, CDORevisionData ? What would be the correct client code to get an older revision
> of a CDO object?
While it is possible and allowed to use CDORevision and CDORevisionData APIs it is usually recommended for lower level
tools (e.g. a history view) and requires some special considerations that are unfortunately not well documented. You'd
access old revisions of an object by, e.g., going through CDOSession.getRevisionManager().getRevisionXyz(...) or,
simpler, CDOUtil.getRevisionByVersion(CDOObject, int). Please note, that especially the access to the *modeled data*
through CDORevisionData is not trivial because the data format is not in all cases identical to the one used by
EObjects. As an example, CDORevisions do not return EObjects as the targets of EReference features, but rather the
CDOIDs of these EObjects and you have to resolve them yourself by using, e.g., a CDORevisionManager.
Generally it's easier to use a CDOView (and CDOTransactions are views, too) to operate on a consitent, EMF-conforming
object graph. A CDOView automatically does all the required data conversion for you. You can easily open multiple such
views from a single repository session and each (non-transactional) view can "look" at a different time (and branch) of
the object graph, see:
org.eclipse.emf.cdo.view.CDOView.setBranchPoint(CDOBranch, long)
org.eclipse.emf.cdo.view.CDOView.setBranchPoint(CDOBranchPoint)
org.eclipse.emf.cdo.view.CDOView.setBranch(CDOBranch)
org.eclipse.emf.cdo.view.CDOView.setTimeStamp(long)
and in CDOSession:
org.eclipse.emf.cdo.view.CDOViewContainer.openView(CDOBranchPoint, ResourceSet)
org.eclipse.emf.cdo.view.CDOViewContainer.openView(CDOBranchPoint)
org.eclipse.emf.cdo.view.CDOViewContainer.openView(CDOBranch, long, ResourceSet)
org.eclipse.emf.cdo.view.CDOViewContainer.openView(CDOBranch, long)
org.eclipse.emf.cdo.view.CDOViewContainer.openView(CDOBranch)
org.eclipse.emf.cdo.view.CDOViewContainer.openView(long)
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO] revisions, Hibernate store. [message #713829 is a reply to message #713810] |
Tue, 09 August 2011 06:56 |
 Christophe Bouhier
Messages: 937
Registered: July 2009 |
Senior Member |
|
|
Hello Eike,
Thank you for the elaborate response, this clarifies.
rgds Christophe.
On 09-08-11 08:00, Eike Stepper wrote:
> Am 08.08.2011 15:28, schrieb Christophe Bouhier:
>> Hi,
>>
>> I have a requirements to keep revision of Objects for some specific
>> objects only.
> CDO, irrespective of the configured IStore implementation or the
> supported repository mode (non-auditing, auditing, branching), does
> always use CDORevisions to capture, transfer and store the current state
> of your objects. So I guess what you really mean is that you don't to
> use auditing for all objects but for some of them. That's not supported
> by CDO because then the framework could not guarantee the consistency of
> the object graph at all times.
>
>
>> I understand, that the revisions feature is not supported with
>> Hibernatestore. Is this confirmed?
> Confirmed.
>
>> I do see, the version number of my objects being incremented on
>> editing. Is this correct behavior?
> Yes, definitely. I already mentioned that CDORevisions are always used
> and they always carry a version number that reflects the number of
> commits that changed the respective object since its initial creation.
> This version number is also used to detect conflicting (possibly
> concurrent) commits in the server.
>
>>
>> Just in case I will be able to use revisions (Perhaps a DB store which
>> works with Postgres) , can anyone please point out how to use the API
>> CDORevision, CDORevisionData ? What would be the correct client code
>> to get an older revision of a CDO object?
> While it is possible and allowed to use CDORevision and CDORevisionData
> APIs it is usually recommended for lower level tools (e.g. a history
> view) and requires some special considerations that are unfortunately
> not well documented. You'd access old revisions of an object by, e.g.,
> going through CDOSession.getRevisionManager().getRevisionXyz(...) or,
> simpler, CDOUtil.getRevisionByVersion(CDOObject, int). Please note, that
> especially the access to the *modeled data* through CDORevisionData is
> not trivial because the data format is not in all cases identical to the
> one used by EObjects. As an example, CDORevisions do not return EObjects
> as the targets of EReference features, but rather the CDOIDs of these
> EObjects and you have to resolve them yourself by using, e.g., a
> CDORevisionManager.
>
> Generally it's easier to use a CDOView (and CDOTransactions are views,
> too) to operate on a consitent, EMF-conforming object graph. A CDOView
> automatically does all the required data conversion for you. You can
> easily open multiple such views from a single repository session and
> each (non-transactional) view can "look" at a different time (and
> branch) of the object graph, see:
>
> org.eclipse.emf.cdo.view.CDOView.setBranchPoint(CDOBranch, long)
> org.eclipse.emf.cdo.view.CDOView.setBranchPoint(CDOBranchPoint)
> org.eclipse.emf.cdo.view.CDOView.setBranch(CDOBranch)
> org.eclipse.emf.cdo.view.CDOView.setTimeStamp(long)
>
> and in CDOSession:
>
> org.eclipse.emf.cdo.view.CDOViewContainer.openView(CDOBranchPoint,
> ResourceSet)
> org.eclipse.emf.cdo.view.CDOViewContainer.openView(CDOBranchPoint)
> org.eclipse.emf.cdo.view.CDOViewContainer.openView(CDOBranch, long,
> ResourceSet)
> org.eclipse.emf.cdo.view.CDOViewContainer.openView(CDOBranch, long)
> org.eclipse.emf.cdo.view.CDOViewContainer.openView(CDOBranch)
> org.eclipse.emf.cdo.view.CDOViewContainer.openView(long)
>
> Cheers
> /Eike
>
> ----
> http://www.esc-net.de
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
>
|
|
|
Goto Forum:
Current Time: Fri Apr 26 04:00:30 GMT 2024
Powered by FUDForum. Page generated in 0.03674 seconds |
] 
Search
Help
Register
Login
Home
