Community
Participate
Working Groups
Support the MDT/OCL aspects of Bug 330988.
Created attachment 184429 [details] 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.
Created attachment 184459 [details] 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.
(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.
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(...).
(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.
(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!
Created attachment 184476 [details] 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.
Created attachment 184477 [details] compile() changed to prepare() available from EMF
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.
(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.
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.
(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.
(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.
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?
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.
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.
Committed to HEAD for M4.
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?
(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.
IP Log for only the latest (Obsolete) patch from contributor.
Closing all bugs resolved in Indigo.
