Home » Modeling » EMF » OCL query failing since migration to Luna M6(ordered set intersection fails if EReference property Ordered=true)
|
Re: OCL query failing since migration to Luna M6 [message #1311418 is a reply to message #1311233] |
Wed, 23 April 2014 19:55 |
Ed Willink Messages: 7655 Registered: July 2009 |
Senior Member |
|
|
Hi
Please use the OCL newsgroup for OCL messages.
You don't provide nearly enough detail to really understand the problem,
but from what you do provide I conclude that a latent bug in your query
has been exposed by more accurate tooling.
You are perhaps falling foul of the preliminary support for Buettner
Collections (On Better Understanding OCL Collections /or/ An OCL Ordered
Set Is Not an OCL Set) that argued that an OrderedSet is a Sequence.
However when discussing OCL 2.5 plans, one of the senior co-authors
persuaded me that the proposed conformance was unsound; addition of a
duplicate to a Sequence leaves the size unchanged whereas the same
operation on the inherited Sequence grows. The support was therefore
retracted on 19-Dec-2013.
Regards
Ed Willink
On 23/04/2014 18:32, Laurent Le Moux wrote:
> Hi all,
>
> Since migrating from Kepler to Luna M6, an OCL query that used to work
> fine is now failing.
>
> I have a first ecore model where a service defines operations.
> I also have a second one where an application may invoke the
> previously defined operations.
>
> Now, for a given service, I want to find all applications that invoke
> at least one of its operations.
>
> My OCL query basically makes an intersection between the applications
> invoked operations and the service defined ones.
>
> But, since my migration to Luna, this intersection is now failing :
>
> Problem executing OCL query:
> applicationv2::Application.allInstances()->select(a:applicationv2::Application|not
> a.invokes->intersection(self.defines)->isEmpty())
>
> org.eclipse.ocl.SemanticException: Cannot find operation
> (intersection(OrderedSet(Operation))) for the type (Sequence(Operation))
>
> How comes that the query now returns a sequence instead of an expected
> ordered set ?
>
> In my ecore models, changing the 'Ordered' property to 'false' for
> both the 'defines' and 'invokes' EReferences solves the problem... 8o
> Regards,
>
> Laurent
|
|
|
Re: OCL query failing since migration to Luna M6 [message #1313206 is a reply to message #1311418] |
Thu, 24 April 2014 19:18 |
Laurent Le Moux Messages: 184 Registered: September 2011 |
Senior Member |
|
|
Hi Ed,
I did not mean to disturb this forum so I'm sorry my post was not clear enough and could be interpreted this way.
I'm far from being an EMF or OCL expert. So, I indeed considered to create a topic in the OCL forum where I actually first looked for a solution to my problem.
But, meanwhile, I did get my OCL query running again with Luna like it used to with Kepler.
However, I didn't change the query itself. The single change I did, took place in my ecore files.
It solves the problem and I could live with it. But, this change doesn't make much sense to me. That's the reason why I did post a topic on the EMF forum, hoping that somebody will give me an explanation.
Back to my problem, I noticed 3 'weird' things :
1. The OCL query running with Kepler didn't anymore with Luna.
2. Looking in my ecore models at the 1..* EReferences I defined, I found an 'Ordered=true' property that looked just fine to me but OCL nevertheless complained about getting a sequence instead of an ordered set when trying to perform an intersection.
3. By setting 'Ordered=false', OCL stops complaining which sounds even stranger to me...
Could it be that the 'ordered' property processing has been somehow 'inverted' between Kepler and Luna releases ?
I could send my ecore files but I doubt it will be of much help...
Kind regards,
Laurent
|
|
|
Re: OCL query failing since migration to Luna M6 [message #1314099 is a reply to message #1313206] |
Fri, 25 April 2014 06:57 |
Ed Willink Messages: 7655 Registered: July 2009 |
Senior Member |
|
|
On 24/04/2014 20:18, Laurent Le Moux wrote:
> Hi Ed,
>
> I did not mean to disturb this forum so I'm sorry my post was not
> clear enough and could be interpreted this way.
So please use the OCL newsgroup (eclipse.modeling.mdt.ocl) as previously
requested.
> I'm far from being an EMF or OCL expert. So, I indeed considered to
> create a topic in the OCL forum where I actually first looked for a
> solution to my problem.
>
> But, meanwhile, I did get my OCL query running again with Luna like it
> used to with Kepler.
> However, I didn't change the query itself. The single change I did,
> took place in my ecore files.
> It solves the problem and I could live with it. But, this change
> doesn't make much sense to me. That's the reason why I did post a
> topic on the EMF forum, hoping that somebody will give me an explanation.
>
> Back to my problem, I noticed 3 'weird' things :
>
> 1. The OCL query running with Kepler didn't anymore with Luna.
>
> 2. Looking in my ecore models at the 1..* EReferences I defined, I
> found an 'Ordered=true' property that looked just fine to me but OCL
> nevertheless complained about getting a sequence instead of an ordered
> set when trying to perform an intersection.
>
> 3. By setting 'Ordered=false', OCL stops complaining which sounds even
> stranger to me...
UML/Ecore modeling define multiplicities
OCL/Ecore evaluation reifies multiplicities as collections
Simplistically, in Ecore, everything is an EList with limited capabilities
In OCL, !ordered+unique => Set, ordered+unique => OrderedSet,
!ordered+!unique => Bag, ordered+!unique => Sequence
so by changing your Ecore declarations you change the Collection type
giving exactly the behavior you observe.
Rather than changing Ecore, you can use e.g. ...->asSet() to convert to
a Set.
Regards
Ed Willink
>
> Could it be that the 'ordered' property processing has been somehow
> 'inverted' between Kepler and Luna releases ?
>
> I could send my ecore files but I doubt it will be of much help...
>
> Kind regards,
>
> Laurent
|
|
|
Goto Forum:
Current Time: Fri Apr 26 21:57:30 GMT 2024
Powered by FUDForum. Page generated in 0.03894 seconds
|