Bug 340719

Comment 1 Axel Uhl 2011-03-23 00:14:28 EDT

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)

Comment 2 Ed Willink 2011-03-23 08:45:02 EDT

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.

Comment 3 Ed Willink 2011-03-23 09:42:21 EDT

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.

Comment 4 Eike Stepper 2011-03-23 16:49:25 EDT

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

Comment 5 Axel Uhl 2011-03-24 04:00:22 EDT

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

Comment 6 Ed Willink 2012-06-02 05:32:12 EDT

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

Comment 7 Ed Willink 2012-06-11 04:17:54 EDT

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.

Comment 8 Ed Willink 2012-06-11 07:35:59 EDT

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

Comment 9 Eike Stepper 2012-08-03 03:10:09 EDT

(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();
    ...