Community
Participate
Working Groups
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.
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.
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.]
Axel: I think this is resolved.
(In reply to comment #3) > Axel: I think this is resolved. You mean by means of the Pivot model?
(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.
Caching run-time compilation is obsoleted by the availability of compile-time code generation of direct Java.
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.
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.
CLOSED after a year in the RESOLVED state.
