[evaluator] review CDO integration

[eclipse-ocl-bot]

| --- | --- | | Bugzilla Link | 340719 | | Status | NEW | | Importance | P3 normal | | Reported | Mar 22, 2011 21:51 EDT | | Modified | Aug 03, 2012 03:10 EDT | | Version | 3.1.0 | | Reporter | Ed Willink |

Description

OCL integration in CDO occurs through a '20 line' server-side module that responds to an OCL string query.

Review this code and assess it's utility, particularly with respect to allInstances().

Consider the ease and appropriateness with which a compact binary XMI query might be passed to the server relieving the server of parsing costs.

[eclipse-ocl-bot]

By Axel Uhl on Mar 23, 2011 00:14

I suggest that in this context we also check for the opportunity to equip the OCL evaluator in the CDO environment with an appropriate OppositeEndFinder implementation which can exploit CDO's efficient cross referencing capabilities.

CDO APIs relevant in this context:

org.eclipse.emf.cdo.view.CDOView.queryXRefs(CDOObject, EReference...)\
org.eclipse.emf.cdo.view.CDOView.queryXRefs(Set<CDOObject>, EReference...)\
org.eclipse.emf.cdo.view.CDOView.queryXRefsAsync(Set<CDOObject>, EReference...)

For their use in the server see, e.g.,

org.eclipse.emf.cdo.internal.server.TransactionCommitContext.XRefContext.getXRefs(IStoreAccessor)

[eclipse-ocl-bot]

By Ed Willink on Mar 23, 2011 08:45

Yes, supporting opposites in CDO, for which OCL doesn't have a long API history may be a good idea. But it points at things to worry about.

Is the CDO client able to control server-side OCL parsing options?

What is the lifetime of the server-side ResourceSet?

How does the client select the environment factory class and construction arguments?

Perhaps we should package all options as a Map in a shareable OCLConfiguration object.

Are we confident that OCL artefacts are released in a server-side environment where perhaps process termination may not occur for a very long time? This probably merits finding out how to do leak detection around our JUnit tests.

[eclipse-ocl-bot]

By Ed Willink on Mar 23, 2011 09:42

Code in SVN at:

http://dev.eclipse.org/svnroot/modeling/org.eclipse.emf.cdo/trunk/plugins/org.eclipse.emf.cdo.server.ocl

After a quick glance:

• The Resource sharing via a Package Registry looks sound, but inflexible.
• Construction of a new OCL for each query is inefficient.
• Recoding of some ObjectUtil routines means at least EBigDecimal and EBigInteger are unhandled.

We should endeavour to migrate as much of this code into a more convenient API so that we can test it, and so that CDO has a much simpler task.

[eclipse-ocl-bot]

By Eike Stepper on Mar 23, 2011 16:49

(In reply to comment #2)

[...] Is the CDO client able to control server-side OCL parsing options?

The queryXRefs() API Axel outlined is a thin convenience wrapper around our general query facility and that is capable of adding arbitrary parameters (key/value pairs) to a CDOQuery instance.

What is the lifetime of the server-side ResourceSet?

It lives for the time the particular query is executed on the server.

How does the client select the environment factory class and construction arguments?

Currently it does not. But I assume it could be done through the aforementioned parameters map.

[eclipse-ocl-bot]

By Axel Uhl on Mar 24, 2011 04:00

Currently it does not. But I assume it could be done through the aforementioned parameters map.

One interesting "parameter" would certainly be an EPackage.Registry in case expressions need to be parsed on the server in order to tell the analyzer where to look up package names (and, optionally, hidden opposites). How is the environment on the server currently populating its Registry, if at all?

[eclipse-ocl-bot]

By Ed Willink on Jun 02, 2012 05:32

See also the need for a clean OCL query return as discussed in Bug 381410#c8.

[eclipse-ocl-bot]

By Ed Willink on Jun 11, 2012 04:17

The pivot model has EObject wrappers, so it may be possible to have a CDOObjectValue that provides more efficient access to CDO APIs and allows allInstances() to exploit CDO's knowledge of the total model.

[eclipse-ocl-bot]

By Ed Willink on Jun 11, 2012 07:35

(In reply to comment #7)

The pivot model has EObject wrappers, so it may be possible to have a CDOObjectValue that provides more efficient access to CDO APIs and allows allInstances() to exploit CDO's knowledge of the total model.

Bug 257102 identiofies limitations in the UML2 meta-model that prevent the genmodel migration working (http://wiki.eclipse.org/CDO/Preparing_EMF_Models#Use_the_CDO_Model_Migrator).

The UML-aligned pivot model could be generally useful for UML implementation tooling if it is pre-migrated to CDO.

[eclipse-ocl-bot]

By Eike Stepper on Aug 03, 2012 03:10

(In reply to comment #5)

One interesting "parameter" would certainly be an EPackage.Registry in case expressions need to be parsed on the server in order to tell the analyzer where to look up package names (and, optionally, hidden opposites). How is the environment on the server currently populating its Registry, if at all?

The server already maintains a central package registry. The package registry in a client's session is mostly a cache that loads packages from the server's registry on demand.

A query handler can use it as follows:

public void executeQuery(CDOQueryInfo info, IQueryContext context)\ {\ CDOPackageRegistry packageRegistry = context.getView().getRepository().getPackageRegistry(); ...