Eclipse Community Forums: EMF » [CDO] OCL Query and sub types

Help

Home

Home » Modeling » EMF » [CDO] OCL Query and sub types

Show: Today's Messages :: Show Polls :: Message Navigator

[CDO] OCL Query and sub types [message #1007987]

Fri, 08 February 2013 14:37

Jan Rosczak

Messages: 53
Registered: July 2009
Location: Hamburg, Germany

Member

Hi,

I have a problem with an OCL query in CDO. Lets say I have the following simple model:

AttributeTable
String name

GreenAttibuteTable extends AttributeTable

BlueAttributeTable extends AttributeTable

Using the query string "AttributeTable.allInstances()" to get all instances of AttributeTables, GreenAttributeTables and BlueAttributeTables does not return any result.

Does the operation "allInstances" not work with sub-types?

Thanks
Jan

Report message to a moderator

Re: [CDO] OCL Query and sub types [message #1008277 is a reply to message #1007987]

Mon, 11 February 2013 05:41

Eike Stepper

Messages: 6682
Registered: July 2009

Senior Member

Am 08.02.2013 15:37, schrieb Jan Rosczak:
> Hi,
>
> I have a problem with an OCL query in CDO. Lets say I have the following simple model:
>
> AttributeTable
> String name
>
> GreenAttibuteTable extends AttributeTable
>
> BlueAttributeTable extends AttributeTable
>
> Using the query string "AttributeTable.allInstances()" to get all instances of AttributeTables, GreenAttributeTables
> and BlueAttributeTables does not return any result.
>
> Does the operation "allInstances" not work with sub-types?
Looking at org.eclipse.emf.cdo.server.ocl.CDOExtentCreator.createExtent() it doesn't seem that subtypes are currently
considered when allInstances() is evaluated. It shouldn't be hard to do, though.

It strikes me that this question has come up already earlier, but I can really not remember when, where (I've search the
forum, bugzilla, with Google and in my private email) or what the outcome was. Maybe Ed Willink )cc'ed) can shed some
light on what the OCL spec says about this?

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper

Report message to a moderator

Re: [CDO] OCL Query and sub types [message #1008278 is a reply to message #1008277]

Mon, 11 February 2013 07:30

Ed Willink

Messages: 7655
Registered: July 2009

Senior Member

Hi Eike

The previous question on allInstances() resulted in me raising Bug
329389, where it appears that a quick code review made me unhappy with
the code. But when I got back to it there was nothing wrong.

allInstances() is in principle very expensive.

By itself, OCL has no clue as to whether a particular invocation of
allInstances() will be followed by further invocations and so cannot
easily optimize the subsequent responses. The default LazyExtentMap
therefore just remembers what it has done previously and does full model
traversals for each new type query.

OCL-extending languages such as QVT*, Acceleo, (ATL, ...) can analyze
their model transformation for allInstances() calls and
replace/configure LazyExtentMap to share one full model traversal for
all actual type queries.

An enhanced model provider such as CDO may have its own type-object
mappings and so may replace LazyExtentMap completely to avoid
duplication, naive model scanning and significantly enhance performance
by using pre-existing knowledge. However a quick browse of the
server.ocl package suggests that LazyExtentMap is not replaced.

---

Since this question has arisen before, there is perhaps some foundation
to it, and since the OCL code seems naively correct, I must point the
finger at the CDO extension.

At present it looks as if OCL on CDO is doing a naive total model scan,
but If you can point me at the code that does something smarter I can
perhaps spot the erroneous exact type/conformant type test.

Regards

Ed

On 11/02/2013 05:41, Eike Stepper wrote:
> Am 08.02.2013 15:37, schrieb Jan Rosczak:
>> Hi,
>>
>> I have a problem with an OCL query in CDO. Lets say I have the
>> following simple model:
>>
>> AttributeTable
>> String name
>>
>> GreenAttibuteTable extends AttributeTable
>>
>> BlueAttributeTable extends AttributeTable
>>
>> Using the query string "AttributeTable.allInstances()" to get all
>> instances of AttributeTables, GreenAttributeTables and
>> BlueAttributeTables does not return any result.
>>
>> Does the operation "allInstances" not work with sub-types?
> Looking at
> org.eclipse.emf.cdo.server.ocl.CDOExtentCreator.createExtent() it
> doesn't seem that subtypes are currently considered when
> allInstances() is evaluated. It shouldn't be hard to do, though.
>
> It strikes me that this question has come up already earlier, but I
> can really not remember when, where (I've search the forum, bugzilla,
> with Google and in my private email) or what the outcome was. Maybe Ed
> Willink )cc'ed) can shed some light on what the OCL spec says about this?
>
> Cheers
> /Eike
>
> ----
> http://www.esc-net.de
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>

Report message to a moderator

Re: [CDO] OCL Query and sub types [message #1009482 is a reply to message #1008278]

Fri, 15 February 2013 08:07

Eike Stepper

Messages: 6682
Registered: July 2009

Senior Member

Am 11.02.2013 08:30, schrieb Ed Willink:
> Hi Eike
>
> The previous question on allInstances() resulted in me raising Bug 329389, where it appears that a quick code review
> made me unhappy with the code. But when I got back to it there was nothing wrong.
Good ;-)

>
> allInstances() is in principle very expensive.
>
> By itself, OCL has no clue as to whether a particular invocation of allInstances() will be followed by further
> invocations and so cannot easily optimize the subsequent responses. The default LazyExtentMap therefore just remembers
> what it has done previously and does full model traversals for each new type query.
So does CDO's extent map. Even the single (lazily computed) sets fill their elements lazily (asynchronously would be
more exact).

> OCL-extending languages such as QVT*, Acceleo, (ATL, ...) can analyze their model transformation for allInstances()
> calls and replace/configure LazyExtentMap to share one full model traversal for all actual type queries.
I think "caching" hits the point better than "lazy". In this simple form it seems to make sense. In a concurrent
environment such as CDO cache invalidation would need to be implemented carefully.

> An enhanced model provider such as CDO may have its own type-object mappings
No, most CDO stores can only compute the type(object) function efficiently.

> and so may replace LazyExtentMap completely to avoid duplication, naive model scanning and significantly enhance
> performance by using pre-existing knowledge. However a quick browse of the server.ocl package suggests that
> LazyExtentMap is not replaced.
We have this:

protected CDOExtentMap createExtentMap(CDOView view, CDOChangeSetData changeSetData, IQueryContext context)
{
CDOExtentCreator creator = createsLazyExtents() ? new CDOExtentCreator.Lazy(view) : new CDOExtentCreator(view);
creator.setChangeSetData(changeSetData);
creator.setRevisionCacheAdder((CDORevisionCacheAdder)context.getView().getRepository().getRevisionManager());
return new CDOExtentMap(creator);
}

>
> ---
>
> Since this question has arisen before, there is perhaps some foundation to it, and since the OCL code seems naively
> correct, I must point the finger at the CDO extension.
>
> At present it looks as if OCL on CDO is doing a naive total model scan,
For sure not.

> but If you can point me at the code that does something smarter I can perhaps spot the erroneous exact type/conformant
> type test.
Please have a look at:

http://git.eclipse.org/c/cdo/cdo.git/tree/plugins/org.eclipse.emf.cdo.server.ocl/src/org/eclipse/emf/cdo/server/ocl/CDOExtentMap.java
http://git.eclipse.org/c/cdo/cdo.git/tree/plugins/org.eclipse.emf.cdo.server.ocl/src/org/eclipse/emf/cdo/server/ocl/CDOExtentCreator.java

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper

>
> Regards
>
> Ed
>
>
>
>
> On 11/02/2013 05:41, Eike Stepper wrote:
>> Am 08.02.2013 15:37, schrieb Jan Rosczak:
>>> Hi,
>>>
>>> I have a problem with an OCL query in CDO. Lets say I have the following simple model:
>>>
>>> AttributeTable
>>> String name
>>>
>>> GreenAttibuteTable extends AttributeTable
>>>
>>> BlueAttributeTable extends AttributeTable
>>>
>>> Using the query string "AttributeTable.allInstances()" to get all instances of AttributeTables, GreenAttributeTables
>>> and BlueAttributeTables does not return any result.
>>>
>>> Does the operation "allInstances" not work with sub-types?
>> Looking at org.eclipse.emf.cdo.server.ocl.CDOExtentCreator.createExtent() it doesn't seem that subtypes are currently
>> considered when allInstances() is evaluated. It shouldn't be hard to do, though.
>>
>> It strikes me that this question has come up already earlier, but I can really not remember when, where (I've search
>> the forum, bugzilla, with Google and in my private email) or what the outcome was. Maybe Ed Willink )cc'ed) can shed
>> some light on what the OCL spec says about this?
>>
>> Cheers
>> /Eike
>>
>> ----
>> http://www.esc-net.de
>> http://thegordian.blogspot.com
>> http://twitter.com/eikestepper
>>
>>
>

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper

Report message to a moderator