Home » Modeling » EMF » Use of OCL with CDO(Use of OCL with CDO)
| Use of OCL with CDO [message #1160723] |
Tue, 29 October 2013 06:05  |
Eclipse User |
|
|
|
Hi,
I'm currently working with a CDOServer (v4.01) and I'm using OCL to get access to model elements.
I've got a few questions concerning OCL in this setup:
1. Is OCL the propper way to request model elements or is there a more common way?
2. Is it possible to use self-defined operations in OCL for realizing recursive functions in OCL?
I want to express something like that:
CDOView.createQuery("ocl", queryText, contextObject.cdoID());
queryText = "
def: hasTitle(t : String) : Boolean = self.job->exists(title = t)
if self.hasTitle('Test') then..."
Exact in this way it doesn't work but maybe there is another way a didn't get by now?
3. Is it possible to use Collections as Context or Parameter in a CDOQuery like:
list = getResultListFromRepository();
CDOView.createQuery("ocl", queryText, list);
or with Parameter:
CDOView.setParameter("name", list);
As far as I can see only Primitive Types, String, Date and Enumeration are possible.
Is there a way to reference Collections in OCL-Queries?
4. Is there a common mechanism to to implement CDO-Queries on the Server (e.g. in Java) and access them on the client-side with the CDO-API?
Any help is appreciated. Thanks a lot,
Stefan
|
|
|
| Re: Use of OCL with CDO [message #1161851 is a reply to message #1160723] |
Tue, 29 October 2013 22:43  |
| Eclipse User |
|
|
|
Hi, Stefan,
See some replies in-line, below.
HTH,
Christian
On 2013-10-30 02:05:21 +0000, Stefan Zeug said:
> Hi,
>
> I'm currently working with a CDOServer (v4.01) and I'm using OCL to get
> access to model elements.
>
> I've got a few questions concerning OCL in this setup:
>
> 1. Is OCL the propper way to request model elements or is there a more
> common way?
I don't understand what you mean by requesting model elements. The
usual entry-point into the contents of a CDO repository is the tree of
resource nodes: folders and resources, in which the resources contain
the model content (folders provide organization as in the file system).
> 2. Is it possible to use self-defined operations in OCL for realizing
> recursive functions in OCL?
>
> I want to express something like that:
>
> CDOView.createQuery("ocl", queryText, contextObject.cdoID());
>
> queryText = "
> def: hasTitle(t : String) : Boolean = self.job->exists(title = t)
> if self.hasTitle('Test') then..."
Not yet. There has been work in the 4.3 (Luna) release to add some
more capabilities to the server-side OCL environment, but to my
knowledge there is not yet any support for loading OCL documents on the
server. That would make an interesting enhancement if someone were
willing to contribute it.
> Exact in this way it doesn't work but maybe there is another way a
> didn't get by now?
No, so far the OCL environment server-side has only access to what is
modeled in your EPackages plus a few CDO-specific extensions.
> 3. Is it possible to use Collections as Context or Parameter in a
> CDOQuery like:
>
> list = getResultListFromRepository();
> CDOView.createQuery("ocl", queryText, list);
>
> or with Parameter:
>
> CDOView.setParameter("name", list);
>
> As far as I can see only Primitive Types, String, Date and Enumeration
> are possible.
> Is there a way to reference Collections in OCL-Queries?
If you tried it and it didn't work, then I would say "no". But it
wouldn't be a difficult change to support collections as query
parameters.
> 4. Is there a common mechanism to to implement CDO-Queries on the
> Server (e.g. in Java) and access them on the client-side with the
> CDO-API?
I don't understand the question. CDO queries are not implemented in
Java: they are are specified in OCL.
> Any help is appreciated. Thanks a lot,
>
> Stefan
|
|
| |
| Re: Use of OCL with CDO [message #1162420 is a reply to message #1161851] |
Wed, 30 October 2013 07:09 |
| Eclipse User |
|
|
|
Hi
It's not quite that simple.
CDO' OCLQueryHandler can return
Primitives
EObjects
Collections of EObject
If you use the closure() iteration you may be able to enough work
server-side to live with the return limitations.
Regards
Ed Willink
On 30/10/2013 03:43, Christian W. Damus wrote:
> Hi, Stefan,
>
> See some replies in-line, below.
>
> HTH,
>
> Christian
>
> On 2013-10-30 02:05:21 +0000, Stefan Zeug said:
>
>> Hi,
>>
>> I'm currently working with a CDOServer (v4.01) and I'm using OCL to
>> get access to model elements.
>>
>> I've got a few questions concerning OCL in this setup:
>>
>> 1. Is OCL the propper way to request model elements or is there a
>> more common way?
>
> I don't understand what you mean by requesting model elements. The
> usual entry-point into the contents of a CDO repository is the tree of
> resource nodes: folders and resources, in which the resources contain
> the model content (folders provide organization as in the file system).
>
>
>> 2. Is it possible to use self-defined operations in OCL for realizing
>> recursive functions in OCL?
>>
>> I want to express something like that:
>>
>> CDOView.createQuery("ocl", queryText, contextObject.cdoID());
>>
>> queryText = "
>> def: hasTitle(t : String) : Boolean = self.job->exists(title = t)
>> if self.hasTitle('Test') then..."
>
> Not yet. There has been work in the 4.3 (Luna) release to add some
> more capabilities to the server-side OCL environment, but to my
> knowledge there is not yet any support for loading OCL documents on
> the server. That would make an interesting enhancement if someone
> were willing to contribute it.
>
>
>> Exact in this way it doesn't work but maybe there is another way a
>> didn't get by now?
>
> No, so far the OCL environment server-side has only access to what is
> modeled in your EPackages plus a few CDO-specific extensions.
>
>
>> 3. Is it possible to use Collections as Context or Parameter in a
>> CDOQuery like:
>>
>> list = getResultListFromRepository();
>> CDOView.createQuery("ocl", queryText, list);
>>
>> or with Parameter:
>>
>> CDOView.setParameter("name", list);
>>
>> As far as I can see only Primitive Types, String, Date and
>> Enumeration are possible.
>> Is there a way to reference Collections in OCL-Queries?
>
> If you tried it and it didn't work, then I would say "no". But it
> wouldn't be a difficult change to support collections as query
> parameters.
>
>
>
>> 4. Is there a common mechanism to to implement CDO-Queries on the
>> Server (e.g. in Java) and access them on the client-side with the
>> CDO-API?
>
> I don't understand the question. CDO queries are not implemented in
> Java: they are are specified in OCL.
>
>
>> Any help is appreciated. Thanks a lot,
>>
>> Stefan
>
>
|
|
|
| Re: Use of OCL with CDO [message #1162572 is a reply to message #1162420] |
Wed, 30 October 2013 09:22 |
| Eclipse User |
|
|
|
Hi, Ed,
On 2013-10-30 11:09:14 +0000, Ed Willink said:
> Hi
>
> It's not quite that simple.
What's not quite that simple? I made a lot of statements. To which is
this a response?
> CDO' OCLQueryHandler can return
>
> Primitives
> EObjects
> Collections of EObject
I thought the question was what can be communicated to the
OCLQueryHandler as parameters. I haven't verified whether collection
values are supported, but I know that the Net4j protocol has no trouble
moving collections of primitives and CDOIDs, so I see no major
impediment to supporting collection parameters if they are not already
supported.
> If you use the closure() iteration you may be able to enough work
> server-side to live with the return limitations.
>
> Regards
>
> Ed Willink
>
> On 30/10/2013 03:43, Christian W. Damus wrote:
>> Hi, Stefan,
>>
>> See some replies in-line, below.
>>
>> HTH,
>>
>> Christian
>>
>> On 2013-10-30 02:05:21 +0000, Stefan Zeug said:
>>
>>> Hi,
>>>
>>> I'm currently working with a CDOServer (v4.01) and I'm using OCL to get
>>> access to model elements.
>>>
>>> I've got a few questions concerning OCL in this setup:
>>>
>>> 1. Is OCL the propper way to request model elements or is there a more
>>> common way?
>>
>> I don't understand what you mean by requesting model elements. The
>> usual entry-point into the contents of a CDO repository is the tree of
>> resource nodes: folders and resources, in which the resources contain
>> the model content (folders provide organization as in the file system).
>>
>>
>>> 2. Is it possible to use self-defined operations in OCL for realizing
>>> recursive functions in OCL?
>>>
>>> I want to express something like that:
>>>
>>> CDOView.createQuery("ocl", queryText, contextObject.cdoID());
>>>
>>> queryText = "
>>> def: hasTitle(t : String) : Boolean = self.job->exists(title = t)
>>> if self.hasTitle('Test') then..."
>>
>> Not yet. There has been work in the 4.3 (Luna) release to add some
>> more capabilities to the server-side OCL environment, but to my
>> knowledge there is not yet any support for loading OCL documents on the
>> server. That would make an interesting enhancement if someone were
>> willing to contribute it.
>>
>>
>>> Exact in this way it doesn't work but maybe there is another way a
>>> didn't get by now?
>>
>> No, so far the OCL environment server-side has only access to what is
>> modeled in your EPackages plus a few CDO-specific extensions.
>>
>>
>>> 3. Is it possible to use Collections as Context or Parameter in a
>>> CDOQuery like:
>>>
>>> list = getResultListFromRepository();
>>> CDOView.createQuery("ocl", queryText, list);
>>>
>>> or with Parameter:
>>>
>>> CDOView.setParameter("name", list);
>>>
>>> As far as I can see only Primitive Types, String, Date and Enumeration
>>> are possible.
>>> Is there a way to reference Collections in OCL-Queries?
>>
>> If you tried it and it didn't work, then I would say "no". But it
>> wouldn't be a difficult change to support collections as query
>> parameters.
>>
>>
>>
>>> 4. Is there a common mechanism to to implement CDO-Queries on the
>>> Server (e.g. in Java) and access them on the client-side with the
>>> CDO-API?
>>
>> I don't understand the question. CDO queries are not implemented in
>> Java: they are are specified in OCL.
>>
>>
>>> Any help is appreciated. Thanks a lot,
>>>
>>> Stefan
|
|
|
| Re: Use of OCL with CDO [message #1162584 is a reply to message #1162264] |
Wed, 30 October 2013 09:32 |
| Eclipse User |
|
|
|
Hi, Stefan,
I see. Yes, the allInstances() operation can certainly be used in this
way to find inverse references. But in the specific case of inverse
references such as A --> B, you will get *much* better performance from
the CDOView::queryXRefs(...) API. This can make use of RDBMS indices
and other facilities that OCL currently cannot; allInstances()
literally loads all A instances from the repository to scan them all.
When it's a question of a longer path between objects, as A --> F --> G
--> B, then in a typical RDBMS you're dealing with a multi-table join.
The queryXRefs API is less helpful here but, if your application can
tolerate a dependence on the particular DB store and table mapping
strategy, CDO does support SQL queries so your client application can
formulate the necessary table join, itself. I haven't much experience
with that ...
If you can possibly scope your search to a particular set of resources
to avoid using allInstances(), you may be able to get reasonable
performance from OCL. Have a look at the enhancements I made in the
server-side OCL environment to support resource-scoped model search in
Papyrus:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=416474
HTH,
Christian
On 2013-10-30 09:05:52 +0000, Stefan Zeug said:
> Hallo Christian,
>
> thanks a lot for the quick answers. They have helped to avoid spending
> time on issues which aren't implemented by now.
>
> Please let me explain my intension to use OCL:
>
> If I have a metamodel with 2 classes A and B and A has a one way
> association x to B.
>
> With OCL I can get all A's referencing b1 of type B with
>
> A.allInstances()-> select(a:A|a.x->includes(self))
>
> So that is what I mean with 'requesting model elements with OCL'.
>
> Imaging a very large model and the model path between A and B is longer.
> Additionally if B is referencing A and I want to get the transitive
> scope of all A's referencing transitive a special B.
>
> In my first question I want to ask if OCL is a good way to realize this
> or if there is another 'best practise' to do so in CDO.
>
> Thanks again for your help,
>
> Stefan
|
|
|
| Re: Use of OCL with CDO [message #1162650 is a reply to message #1162572] |
Wed, 30 October 2013 10:24 |
| Eclipse User |
|
|
|
Hi Christian
The rest of your comments seem very accurate, so I was only clarifying
the return for which I contributed a minor RC3 tweak via
https://bugs.eclipse.org/bugs/show_bug.cgi?id=381410. Comment 9 makes
clear that proper returns need a customer requirement. I only looked at
the return. Glancing at the
parameters similar limitations exist there too.
Regards
Ed Willink
On 30/10/2013 14:22, Christian W. Damus wrote:
> Hi, Ed,
>
> On 2013-10-30 11:09:14 +0000, Ed Willink said:
>
>> Hi
>>
>> It's not quite that simple.
>
> What's not quite that simple? I made a lot of statements. To which
> is this a response?
>
>
>> CDO' OCLQueryHandler can return
>>
>> Primitives
>> EObjects
>> Collections of EObject
>
> I thought the question was what can be communicated to the
> OCLQueryHandler as parameters. I haven't verified whether collection
> values are supported, but I know that the Net4j protocol has no
> trouble moving collections of primitives and CDOIDs, so I see no major
> impediment to supporting collection parameters if they are not already
> supported.
>
>
>> If you use the closure() iteration you may be able to enough work
>> server-side to live with the return limitations.
>
>>
>> Regards
>>
>> Ed Willink
>>
>> On 30/10/2013 03:43, Christian W. Damus wrote:
>>> Hi, Stefan,
>>>
>>> See some replies in-line, below.
>>>
>>> HTH,
>>>
>>> Christian
>>>
>>> On 2013-10-30 02:05:21 +0000, Stefan Zeug said:
>>>
>>>> Hi,
>>>>
>>>> I'm currently working with a CDOServer (v4.01) and I'm using OCL to
>>>> get access to model elements.
>>>>
>>>> I've got a few questions concerning OCL in this setup:
>>>>
>>>> 1. Is OCL the propper way to request model elements or is there a
>>>> more common way?
>>>
>>> I don't understand what you mean by requesting model elements. The
>>> usual entry-point into the contents of a CDO repository is the tree
>>> of resource nodes: folders and resources, in which the resources
>>> contain the model content (folders provide organization as in the
>>> file system).
>>>
>>>
>>>> 2. Is it possible to use self-defined operations in OCL for
>>>> realizing recursive functions in OCL?
>>>>
>>>> I want to express something like that:
>>>>
>>>> CDOView.createQuery("ocl", queryText, contextObject.cdoID());
>>>>
>>>> queryText = "
>>>> def: hasTitle(t : String) : Boolean = self.job->exists(title = t)
>>>> if self.hasTitle('Test') then..."
>>>
>>> Not yet. There has been work in the 4.3 (Luna) release to add some
>>> more capabilities to the server-side OCL environment, but to my
>>> knowledge there is not yet any support for loading OCL documents on
>>> the server. That would make an interesting enhancement if someone
>>> were willing to contribute it.
>>>
>>>
>>>> Exact in this way it doesn't work but maybe there is another way a
>>>> didn't get by now?
>>>
>>> No, so far the OCL environment server-side has only access to what
>>> is modeled in your EPackages plus a few CDO-specific extensions.
>>>
>>>
>>>> 3. Is it possible to use Collections as Context or Parameter in a
>>>> CDOQuery like:
>>>>
>>>> list = getResultListFromRepository();
>>>> CDOView.createQuery("ocl", queryText, list);
>>>>
>>>> or with Parameter:
>>>>
>>>> CDOView.setParameter("name", list);
>>>>
>>>> As far as I can see only Primitive Types, String, Date and
>>>> Enumeration are possible.
>>>> Is there a way to reference Collections in OCL-Queries?
>>>
>>> If you tried it and it didn't work, then I would say "no". But it
>>> wouldn't be a difficult change to support collections as query
>>> parameters.
>>>
>>>
>>>
>>>> 4. Is there a common mechanism to to implement CDO-Queries on the
>>>> Server (e.g. in Java) and access them on the client-side with the
>>>> CDO-API?
>>>
>>> I don't understand the question. CDO queries are not implemented in
>>> Java: they are are specified in OCL.
>>>
>>>
>>>> Any help is appreciated. Thanks a lot,
>>>>
>>>> Stefan
>
>
|
|
| | |
| Re: Use of OCL with CDO [message #1162892 is a reply to message #1162705] |
Wed, 30 October 2013 13:50 |
| Eclipse User |
|
|
|
Hi, Ed,
Perhaps you're thinking of the support that Eike added for
EObject.allInstances() to iterate (if a user really wants to) all
objects in the repository? Or the support I added for the
impicit-root-class-option (which is useful to specify as EObject)?
It is worth noting (as you know, but for the benefit of other readers)
that server-side OCL in CDO uses the classic environment, not the Pivot.
cW
On 2013-10-30 15:05:46 +0000, Ed Willink said:
> Hi
>
> closure() became a standard part of OCL in 2.3. Christian prototyped it
> in Eclipse many years earlier. It has no special CDO specific
> functionality; just the same as forAll is a generic capability.
>
> Christian: I vaguely recall Eike talking about an improved OCL
> Environment for CDO that at least respected inheritance; perhaps this
> should exploit the queryXRef-API.
>
> Regards
>
> Ed Willink
>
> On 30/10/2013 15:54, Stefan Zeug wrote:
>> Hi,
>>
>> Ed, you mentioned the closure() iteration.
>> Can you please give an example how to use it in the context of CDO?
>>
>> Christian, I try to avoid a dependency to the concret DB. That's the
>> reason why I want to use OCL.
>> But I will have a closer look at the queryXRef-API. Perhaps the
>> performnce will be better for some queries.
>>
>> Thanks a lot for your answers,
>>
>> Stefan
|
|
| | | | |
| Re: Use of OCL with CDO [message #1165564 is a reply to message #1165355] |
Fri, 01 November 2013 07:24 |
| Eclipse User |
|
|
|
Indeed, thanks for clarifying that, Eike.
My answer was erroneous because I misread "CDO-Queries" as
"OCL-Queries" in the question.
Too many TLAs!
:-$
On 2013-11-01 08:13:26 +0000, Eike Stepper said:
> Am 30.10.2013 03:43, schrieb Christian W. Damus:
>>
>>> 4. Is there a common mechanism to to implement CDO-Queries on the
>>> Server (e.g. in Java) and access them on the client-side with the
>>> CDO-API?
>>
>> CDO queries are not implemented in Java: they are are specified in OCL.
> That's not exactly true. OCL is one way to query a CDO repository but
> there are also other implementations of the IQueryHandler interface,
> such as the SQLQueryHandler and the HQLQueryHandler. Users can also
> contribute their own implementation to a repository. It's best to look
> at our existing implementations to see how easy it is. A test
> implementation is in
> org.eclipse.emf.cdo.internal.server.mem.MEMStoreAccessor.testQueryHandler.
> Custom query handlers can be contributed by registering a
> org.eclipse.emf.cdo.spi.server.QueryHandlerFactory, see the plugin.xml
> of the server.ocl plugin.
>
> Cheers
> /Eike
>
> ----
> http://www.esc-net.de
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
|
|
|
Goto Forum:
Current Time: Wed May 07 18:37:45 EDT 2025
Powered by FUDForum. Page generated in 0.03963 seconds |
Home