Skip to content

Latest commit

 

History

History
executable file
·
217 lines (146 loc) · 10.9 KB

HELP.md

File metadata and controls

executable file
·
217 lines (146 loc) · 10.9 KB

Getting Started

Spring

Reference Documentation

For further reference, please consider the following sections:

Eclipse CDO

  • provides means to store/load bigraphical models to/from a CDO server

Hint: net4j version of the CDO Server itself must match with the Maven dependency used in this project. Otherwise an exception is thrown similar to: org.eclipse.net4j.channel.ChannelException: Failed to register channel with peer: Protocol version 37 does not match expected version 34

  • Installation: Possible via the Eclipse Installer (Select Eclipse CDO Server in the list and select the correct product version, see below)

  • After fetching all Eclipse CDO dependencies, they shall be deployed to Artifactory

    • First, deploy the JARs inside the spring-data-cdo-distribution/target/repository/plugins/ folder
      • via the UI, select "As Maven artifact"
    • Second, replace the POM file of each artifact in Artifactory by the one in the local Maven repository under ~/.m2/
      • it might be necessary to modify the group id of the "installed pom file" in ~/.m2 -> this depends on where Artifactory places the first JAR

Compatible Versions

These versions of the Eclipse CDO Server and Maven Dependencies are working together:

FAQ: https://wiki.eclipse.org/FAQ_for_CDO_and_Net4j - How can I react to remote changes to my objects? - What happens in case of a conflict (two transactions changing the same object)? - transaction.options.addConflictResolver

CDO Server

Performance Issue

Tweaking:

OCL

pure: https://help.eclipse.org/kepler/index.jsp?topic=%2Forg.eclipse.ocl.doc%2Fhelp%2FCustomizingtheEnvironment.html

CDO-OCL Queries: we need the eclass of the entity in question (working examples) createQuery(cdoTransaction, "Book.allInstances()->size()", ((BookstoreDomainModelPackage)context).getBook()).getResult() createQuery(cdoTransaction, "Book.allInstances()->size()", ((BookstoreDomainModelPackage)EPackage.Registry.INSTANCE.getEPackage(persistentEntity.getNsUri())).getBook()).getResult() CDOQuery query = createQuery(cdoTransaction, "EObject.allInstances()", EcorePackage.eINSTANCE.getEObject()); CDOQuery query2 = createQuery(cdoTransaction, "EObject.allInstances()->size()", EcorePackage.eINSTANCE.getEObject()); cdoTransaction.createQuery("ocl", "bookstoreDomainModel::Book.allInstances()->size()").getResultValue() // not supported exception

CDO Client

Client examples:

http://www.rcp-vision.com/cdo-connected-data-objects/ https://wiki.eclipse.org/CDO/Hibernate_Store/Tutorial

CDO Queries

  • OCL, SQL, or CDO-like

https://wiki.eclipse.org/CDOQuery_OCL https://www.eclipse.org/forums/index.php/t/760318/ https://bugs.eclipse.org/bugs/show_bug.cgi?id=435807

CDOID

from https://www.eclipse.org/forums/index.php/t/450110/:

So now we should have 2 versions of this Company object in the database. Say we make a couple of more updates to this Company record's city (2 more would make 4 versions). The CDOID will be the same and uniquely identifiers it (please let me know if this is not the case. I'm fairly certain I read that a CDOID is unique for a repository ("/repo1" in this case)). Totally correct. The CDOID is unique for a CDOObject in an IRepository. All CDORevisions (in both time and branch dimensions) of this CDOObject share the same CDOID.

Fetch by CDOID: https://www.eclipse.org/forums/index.php/t/135470/

This makes also the CDOID up:

String uriFragment = resource.getURIFragment(eObject);
String uriFragment = EcoreUtil.getURI(eObject).fragment();

CDOUtil.getCDOObject(eObject).cdoID();

Both can be used to retrieve an object from a resource.

https://www.eclipse.org/forums/index.php/t/136782/:

  1. detach/reattach an object Whenever an object is detached from the graph it looses all its CDO-specific properties: id, state, view and revision.

Converters:

Conflicts

from: https://www.eclipse.org/forums/index.php/t/452339/

  • just provide user-defined handlers... if not set throw an exception.

Further Context

Transactions and Views

  • Transaction are like parallel shared subsession over a unique distinct session only after commit things gets merged one can lock objects (w/o committing) and the other transaction gets aware of it automatically

  • from: https://www.eclipse.org/forums/index.php/t/450110/ A CDOView or CDOTransaction provides consistent access to the CDOObject graph at a certain point in time in a certain branch (e.g. the MAIN branch). You can navigate this graph through EMF API and will never leave this time/branch. A CDOTransaction always "looks" at the latest time in its branch, while a pure CDOView can "wind back time". Views and transactions are revision selectors , where a revision is the state of a single object for a certain period of time in a certain branch.

    With a transaction you can modify the object graph atomically. The transitions between two consecutive commits are described by CDOCommitInfos. They're returned from transaction.commit() and can later be recreated, e.g., through session.getCommitInfoManager() methods. It's often more convenient to use the newer CDOCommitHistory or CDOObjectHistory APIs as returned by implementations of CDOCommitHistory.Provider. A commit history is an ordered collection of CDOCommitInfos (also used by our CDOHistoryPage contribution to the Eclipse "History" view part). The availablity of historical commit infos and the cost to recreate them may depend on the used IStore.

    CDOCommitInfos contain/provide the deltas between two consecutive sets of CDORevisions (the states of relevant objects before and after a commit). They know nothing about CDOViews, CDOTransactions or CDOObjects (other than their CDOIDs). But you can always turn a CDOID into a CDOObject (and the associated object graph) by opening a CDOView at the time and branch that's associated with the CDOCommitInfo (and all its deltas and resulting revisions). That's what we do in our EMF Compare integration as you can see by double clicking a commit info in the CDOHistoryPage.

Revisions

from: https://www.eclipse.org/forums/index.php/t/265043/ There's a low-level API to access arbitrary revisions: CDORevisionManager, i.e. session.getRevisionManager(). But on the CDORevision layer navigation is not directly possible.

If you want to access the entire object graph at a different, historical time it's more convenient to open a CDOView on the same session and set the (target) timestamp. You can do that when opening the view or even later via setTimeStamp(). A CDOView has a getObject(T) method that you can use to directly jump to an object from another view (your transaction in this case).

CDOView: "Think of a CDOView as a read-only transaction, it has most of the (same) methods for accessing models. In fact a CDOTransaction is a sub type of a CDOView"

"For a given CDOObject (and with auduting enabled in the server) you can access any revision with these methods:

CDOUtil.getRevisionByVersion(CDOObject, int) CDOUtil.getRevisionByVersion(CDOObject, CDOBranch, int)

If you need the "CDOObjects" for these revisions you must open audit views for the time stamps of these revisions:

int version = 1; CDOView audit = object.cdoView().getSession.openView(CDOUtil.getRevision(object, version).getTimeStamp()); CDOObject oldObject = audit.getObject(object);"

Use CDOBranchPoint.UNSPECIFIED_DATE to reset the view back for looking at the latest state of the object.

Revision Count https://www.eclipse.org/forums/index.php/t/450110/ "You can ask for the version of the latest revision of an object by:

a) If you have a view/transaction open: view.getObject(id).cdoRevision().getVersion() or

b) by using the revision manager: session.getRevisionManager().getRevision(id, mainBranch.getHead(), ...).getVersion()

If you only use one branch (the main branch) that version is equal to the number of revisions of that object."