[evaluator] Provide a generic ODA driver implementation for EMF models

[eclipse-ocl-bot]

| --- | --- | | Bugzilla Link | 331143 | | Status | CLOSED FIXED | | Importance | P3 enhancement | | Reported | Nov 25, 2010 12:36 EDT | | Modified | May 29, 2012 13:21 EDT | | Version | 3.0.0 | | Depends on | 330988 | | Reporter | Ed Willink |

Description

Support the MDT/OCL aspects of Bug 330988.

[eclipse-ocl-bot]

By Kenn Hussey on Dec 02, 2010 20:28

Created attachment 184429 (attachment deleted)\ OCL query delegate implementation

Now that the core EMF changes have been committed, here is a (final?) patch for an OCL query delegate implementation which includes unit tests.

[eclipse-ocl-bot]

By Ed Willink on Dec 03, 2010 07:34

Created attachment 184459 (attachment deleted)\ Revised patch with compile(), invalid return, more tests

In OCL, invalid is a computable value and so a computed invalid value should be returned. (A forthcoming change will allow an invalid value to carry an exception cause or string reason.) I have therefore changed the return so that an InvocationTargetException is thrown for framework problems, while invalid is returned for computational results. Once invalid carries an exception, it may be possible to restore framework errors that are wrapped as invalid within computations back to InvocationTargetException.

I have separated the query preparation into a compile() method that is invoked lazily from execute(). If this is added to the QueryDelegate interface, users can choose to compile() eagerly. The constructor no longer throws an exception.

I have added validation of context type and argument names and types so that these produce InvocationTargetException rather than obscure downstream evaluation invalids.

I have modified the OCLQueryDelegateFactory to have a default Global implementation that can redirect via a ResourceSet registry in the same way as the other Delegate registries.

Additional testing checks the above, and also validates that a local delegate registry is in use when requested.

I have also increased the o.e.o dependency to EMF 2.7. There doesn't seem much point in doing this temporarily only for o.e.o.ecore.

[eclipse-ocl-bot]

By Kenn Hussey on Dec 03, 2010 09:13

(In reply to comment #2)

Created an attachment (id=184459) [details] Revised patch with compile(), invalid return, more tests

Ed, these changes sound great, thanks. Could I just request that we use "prepare" instead of "compile", and that we consider possibly moving the parameters and expression arguments to that method? I would appreciate a timely response so that I can change what's already been committed to EMF as quickly as possible and run a build containing all of this stuff.

[eclipse-ocl-bot]

By Ed Willink on Dec 03, 2010 10:30

Moving the entire constructor argument list to 'prepare' doesn't actually work. There are two argument data sets:

Configuration: self-type,variable-names+types,body-string\ Invocation: self-instance,variable-instances

Construction requires the self-type to locate the delegate domain, so there seems little point in migrating the configuration data out of the constructor phase, although it could be in an init method to aid derived implementations or re-initialization.

The 'prepare' is argumentless if lazy.

I therefore favour just renaming 'compile' to 'prepare'. You may also want to add init(...).

[eclipse-ocl-bot]

By Kenn Hussey on Dec 03, 2010 10:36

(In reply to comment #4)

I therefore favour just renaming 'compile' to 'prepare'. You may also want to add init(...).

OK, let's go with an argumentless prepare(). No need for init for now. I'll commit changes to EMF shortly.

[eclipse-ocl-bot]

By Kenn Hussey on Dec 03, 2010 10:53

(In reply to comment #5)

OK, let's go with an argumentless prepare(). No need for init for now. I'll commit changes to EMF shortly.

I've committed the changes to EMF. If you could update the OCL patch, I'll apply it and test it out with the ODA driver. Thanks!

[eclipse-ocl-bot]

By Kenn Hussey on Dec 03, 2010 11:21

Created attachment 184476 (attachment deleted)\ updated path (with "prepare")

Here's an updated version of the patch which uses "prepare" and which has been tested (successfully) with the driver. I would be eternally grateful if you could commit these changes soon.

[eclipse-ocl-bot]

By Ed Willink on Dec 03, 2010 11:32

Created attachment 184477 compile() changed to prepare() available from EMF

:notepad_spiral: Bug331143.patch

[eclipse-ocl-bot]

By Ed Willink on Dec 03, 2010 11:37

Adolfo: this patch is now ok with me and Kenn, so we don't need another review; unless you need something to do?

However it raises the emf.ecore dependency to 2.7.0 and uses the latest emf.ecore CVS which will be in M4.

Please let me know when you would like this committed since we will need to use some EMF I-builds until M4 is out.

[eclipse-ocl-bot]

By Kenn Hussey on Dec 03, 2010 11:41

(In reply to comment #9)

Adolfo: this patch is now ok with me and Kenn, so we don't need another review; unless you need something to do?

I've tested your version of the updated patch and it looks good.

Please let me know when you would like this committed since we will need to use some EMF I-builds until M4 is out.

I'll be posting an I-build of EMF with the changes as soon as possible after these changes are committed, i.e., early next week.

[eclipse-ocl-bot]

By Ed Willink on Dec 03, 2010 11:47

Kenn:\ We're colliding. Your patch didn't pick up the corrolories,\ redundant casts in tests, references to compile in documentation.

I think we need an EMF I-build to avoid OCL N-builds breaking, so I don't think we can commit until the I-build early next week.

I'd also like to give other committers a couple of days to -1, if they feel it appropriate.

[eclipse-ocl-bot]

By Kenn Hussey on Dec 03, 2010 13:49

(In reply to comment #11)

Kenn: We're colliding. Your patch didn't pick up the corrolories, redundant casts in tests, references to compile in documentation.

Sorry about that. I used your latest patch in my testing, and it looks good.

I think we need an EMF I-build to avoid OCL N-builds breaking, so I don't think we can commit until the I-build early next week.

I'll try to post an I build of EMF, containing just the core changes, ASAP so that OCL can pick it up.

I'd also like to give other committers a couple of days to -1, if they feel it appropriate.

OK. Since everything is nicely decoupled, I can actually move forward with committing (and building) the other EMF changes before the OCL changes have been committed. So take your time. Thanks again for helping me get this in for M4.

[eclipse-ocl-bot]

By Kenn Hussey on Dec 03, 2010 16:42

(In reply to comment #12)

I'll try to post an I build of EMF, containing just the core changes, ASAP so that OCL can pick it up.

Integration build I201012031543 of EMF 2.7.0 is now available.

[eclipse-ocl-bot]

By Ed Willink on Dec 07, 2010 11:49

Adolfo: Are you there? I would like to commit this. It should be relatively benigh now that there is an EMF I-build. Any problems?

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on Dec 09, 2010 04:47

Hi Guys,

Apologizes. I've been lost some days in the north of my island (Monday and Wednesday were bank holidays in Spain) and I haven't had any time to be up to date with the email...

Running my Eclipse to do a quick look at the code.

Cheers,\ Adolfo.

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on Dec 09, 2010 05:54

Concerning the patch, it looks ok to me.

I've also updated our rmap file to feed our build with EMF I-builds repository.

I've just run a new build to see what happens, because EMF p2 repositories now have a new/strange organization ;P.

As soon as the patch is committed, I'll also launch an integration build for any interested client.

Cheers,\ Adolfo.

[eclipse-ocl-bot]

By Ed Willink on Dec 09, 2010 12:17

Committed to HEAD for M4.

[eclipse-ocl-bot]

By Alex on Dec 09, 2010 15:17

I am curious whether this would support server-side OCL queries on CDO? Or would there have to be a different delegate implementation for this?

[eclipse-ocl-bot]

By Kenn Hussey on Dec 09, 2010 15:45

(In reply to comment #18)

I am curious whether this would support server-side OCL queries on CDO? Or would there have to be a different delegate implementation for this?

It already works with CDO models (by using a URI with the cdo protocol, e.g., cdo.net4j.tcp://user:pw@host:port/repo1/myresource?branch=MAIN&time=HEAD&transactional=true) but if you're looking for server-side query execution then yes, you would need a different delegate.

[eclipse-ocl-bot]

By Ed Willink on Dec 15, 2010 11:32

IP Log for only the latest (Obsolete) patch from contributor.

[eclipse-ocl-bot]

By Ed Willink on May 29, 2012 13:21

Closing all bugs resolved in Indigo.