[ast] Persistent caching of pre-compiled expressions

[eclipse-ocl-bot]

| --- | --- | | Bugzilla Link | 334821 | | Status | CLOSED WONTFIX | | Importance | P3 normal | | Reported | Jan 19, 2011 14:09 EDT | | Modified | May 20, 2013 11:37 EDT | | Version | 3.1.0 | | Reporter | Axel Uhl |

Description

As a spin-off of https://bugs.eclipse.org/bugs/show_bug.cgi?id=329167 which from now on will only deal with the transient caching of compiled expressions, this bug concerns persistent caching only. Currently, there are two different EAnnotation sources for OCL-related stuff: OCLDelegateDomain.OCL_DELEGATE_URI ("http://www.eclipse.org/emf/2002/Ecore/OCL") and Environment.OCL_NAMESPACE_URI ("http://www.eclipse.org/ocl/1.1.0/OCL"). The former is used to store OCL expressions as strings, the latter is used to store definitions attached to elements such as properties (derivation expression) or operations (body expression). It would be useful to harmonize this.

Suggestion: look up the compiled AST first in the OCLDelegateDomain.OCL_DELEGATE_URI annotation; then, for backward compatibility, keep checking in the old location (Environment.OCL_NAMESPACE_URI) which would be deprecated and removed in some future release.

[eclipse-ocl-bot]

By Axel Uhl on Jan 20, 2011 08:16

It may be noted that currently the EcoreEnvironment.getDefinition operation already fetches ASTs from annotations which may be stored durably in an Ecore resource. The missing piece is in particular a persistent storage location for invariants used during validation.

Suggestion: store the invariant Constraints objects the same way in an Ecore resource as is used for the operation/property bodies, namely in the contents of an OCL_NAMESPACE_URI annotation.

[eclipse-ocl-bot]

By Ed Willink on Jan 30, 2011 07:39

I think that there is a third EAnnotation URI used when a UML model with an OpaqueExpression constraint is exported to Ecore.

The various workers on the Ecore delegates were, I suspect, variously ignorant of, or forgetful of, the pre-existing mechanisms.

It would be good to go through old tutorials and current tools to rediscover the old mechanisms and support them on input. Please document in a wiki page and/or Documentation contribution; list of persistence mechanisms, list of creation tooling, list of consumption tooling.

Since there is currently no AST persistence, it is presumably safe to define any AST in an input model as the master with respect to a conflicting textual representation, so the AST can be stored in the eContents of the OCLDelegateDomain.OCL_DELEGATE_URI EAnnotation that currently has an eAdapter. No need for correlation of eContents and eDetails, the AST should be self-describing and uncorrelated with eDetails.

Since changing the eContents involves a Resource change, I think we load automatically, but require explicit use of a helper function to put the AST in the persistent eContents and/or trash the eContents in favour of a text string.

[This problem goes away in the Pivot model where a Constraint has a specification which may be an OpaqueExpression containing a multi-lingual set of expression strings, or an ExpressionInOcl containing the AST. However when saving the Pivot as Ecore, the above policy should work fine.]

[eclipse-ocl-bot]

By Ed Willink on Mar 14, 2011 16:29

Axel: I think this is resolved.

[eclipse-ocl-bot]

By Axel Uhl on Mar 14, 2011 18:06

(In reply to comment #3)

Axel: I think this is resolved.

You mean by means of the Pivot model?

[eclipse-ocl-bot]

By Ed Willink on Mar 15, 2011 02:31

(In reply to comment #4)

(In reply to comment #3)

Axel: I think this is resolved.

You mean by means of the Pivot model?

Sorry. Not reading the title. PERSISTENT.

[eclipse-ocl-bot]

By Ed Willink on Nov 07, 2011 16:59

Caching run-time compilation is obsoleted by the availability of compile-time code generation of direct Java.

[eclipse-ocl-bot]

By Axel Uhl on Nov 08, 2011 03:26

Quick question: where does Java code get generated if I don't genmodel? I doubt that Java code generation is a full replacement for persistently caching the OCL AST in the Ecore model.

[eclipse-ocl-bot]

By Ed Willink on Nov 08, 2011 03:54

There is no on the fly Java Code Generation so dynamic EMF OCL is interpreted.

I assumed that anyone concerned about performance would genmodel.

If you have a use case for significant dynamic EMF OCL, either reopen this bug, to support caching, or open a new bug to support JIT code generation.

JIT code generation shouldn't be that hard, but it probably needs Java 6 to provide a friendly interface to the Java compiler and Java 7 to make a ClassLoader reload easily.

[eclipse-ocl-bot]

By Ed Willink on May 20, 2013 11:37

CLOSED after a year in the RESOLVED state.