Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » [CDO] OCL query failing on a newly started CDO server...(...and not anymore when the corresponding element has been loaded once !)
[CDO] OCL query failing on a newly started CDO server... [message #1362730] Sat, 17 May 2014 16:10 Go to next message
Laurent Le Moux is currently offline Laurent Le Moux
Messages: 147
Registered: September 2011
Senior Member
Hi all,

I have a problem with the following OCL query :
mm::pictograms::Diagram.allInstances()->select(d:mm::pictograms::Diagram | d.children.link.businessObjects->includes(self))


It fails with a "org.eclipse.ocl.SemanticException: Unknown type ([mm, pictograms, Diagram])", but only in a specific situation.

The query is run against a CDO repository. And it fails if it is run directly after the CDO server has been started.

Whereas it succeeds if whatever diagram stored in the repository has been loaded once by any CDO client in a "classical way" (that is, by accessing a diagram in a transaction.getResource(XXX) content), before my application issues the query.

I tried to solve my problem by registering the necessary packages with lines like the following one :
session.getPackageRegistry().putEPackage(PictogramsPackage.eINSTANCE);


But it makes no difference and I found no other clue while browsing various topics.
Could somebody please tell me what's wrong ?

Kind regards,

Laurent
Re: [CDO] OCL query failing on a newly started CDO server... [message #1369187 is a reply to message #1362730] Tue, 20 May 2014 09:11 Go to previous messageGo to next message
Christian W. Damus is currently offline Christian W. Damus
Messages: 775
Registered: July 2009
Senior Member
Hi, Laurent,

In order for a server-side OCL query to parse, the server needs to know
the EPackages involved. This happens implicitly when committing
instances of those EPackages, of course, but I don't think that adding
it to the client-side session package registry affects the server in
any way.

If you need to execute this query (presumably getting an empty result)
before the repository contains any instances of your EPackage, you
could pre-register the package in your server's XML configuration:

<initialPackage nsURI="http://whatever/is/the/pictogram/package/nsuri"/>

HTH,

Christian

On 2014-05-17 20:10:04 +0000, Laurent Le Moux said:

> Hi all,
>
> I have a problem with the following OCL query :
>
> mm::pictograms::Diagram.allInstances()->select(d:mm::pictograms::Diagram
> | d.children.link.businessObjects->includes(self))
>
>
> It fails with a "org.eclipse.ocl.SemanticException: Unknown type ([mm,
> pictograms, Diagram])", but only in a specific situation.
>
> The query is run against a CDO repository. And it fails if it is run
> directly after the CDO server has been started.
>
> Whereas it succeeds if whatever diagram stored in the repository has
> been loaded once by any CDO client in a "classical way" (that is, by
> accessing a diagram in a transaction.getResource(XXX) content), before
> my application issues the query.
>
> I tried to solve my problem by registering the necessary packages with
> lines like the following one :
>
> session.getPackageRegistry().putEPackage(PictogramsPackage.eINSTANCE);
>
>
> But it makes no difference and I found no other clue while browsing
> various topics.
> Could somebody please tell me what's wrong ?
>
> Kind regards,
>
> Laurent
Re: [CDO] OCL query failing on a newly started CDO server... [message #1369645 is a reply to message #1369187] Tue, 20 May 2014 13:32 Go to previous messageGo to next message
Laurent Le Moux is currently offline Laurent Le Moux
Messages: 147
Registered: September 2011
Senior Member
Hi Christian,

Thanks for your answer. I tried to add your statement in my cdo-server.xml:
<initialPackage nsURI="http://eclipse.org/graphiti/mm"/>
<initialPackage nsURI="http://eclipse.org/graphiti/mm/algorithms"/>
<initialPackage nsURI="http://eclipse.org/graphiti/mm/algorithms/styles"/>
<initialPackage nsURI="http://eclipse.org/graphiti/mm/pictograms"/>


But the server then refuses to start with a 'JdbcSQLException: Unique index or primary key violation' message (see attached log).

Moreover, when I execute my query, the repository is not empty. So I would not get an empty result back.
But, as the server has just been restarted, it seems that the implicit EPackage loading you described does not take place.

So, I had a look to the CDO Explorer package registry and it appears the Graphiti packages are correctly loaded (see attached screenshot):

index.php/fa/18118/0/

Whereas, when I add traces to list the registered packages in my application, only the first Graphiti package is registered !
Id : http://application/2.0, State : PROXY, Type : LEGACY, Original : NATIVE
Id : http://eclipse.org/graphiti/mm, State : PROXY, Type : LEGACY, Original : NATIVE
Id : http://lemoux.fr/modeling/framework/commons/metadata/commit, State : PROXY, Type : LEGACY, Original : NATIVE
Id : http://lemoux.fr/modeling/framework/commons/metadata/configuration, State : PROXY, Type : LEGACY, Original : NATIVE
Id : http://repositorystructure/2.0, State : PROXY, Type : LEGACY, Original : NATIVE
Id : http://service/2.0, State : PROXY, Type : LEGACY, Original : NATIVE
Id : http://user/1.0, State : PROXY, Type : LEGACY, Original : NATIVE
Id : http://www.eclipse.org/emf/2002/Ecore, State : PROXY, Type : LEGACY, Original : LEGACY
Id : http://www.eclipse.org/emf/CDO/Eresource/4.0.0, State : PROXY, Type : NATIVE, Original : NATIVE
Id : http://www.eclipse.org/emf/CDO/Etypes/4.0.0, State : PROXY, Type : NATIVE, Original : NATIVE
Id : http://www.eclipse.org/emf/CDO/expressions/4.3.0, State : PROXY, Type : LEGACY, Original : NATIVE
Id : http://www.eclipse.org/emf/CDO/security/4.1.0, State : PROXY, Type : LEGACY, Original : NATIVE

I then tried again to register the 3 missing packages (like in Eike's StandaloneContainerExample in the CDO Wiki snippets) :
// Register missing Graphiti packages
session.getPackageRegistry().putEPackage(AlgorithmsPackage.eINSTANCE);
session.getPackageRegistry().putEPackage(StylesPackage.eINSTANCE);
session.getPackageRegistry().putEPackage(PictogramsPackage.eINSTANCE);

// List registered packages
for (CDOPackageUnit pu : session.getPackageRegistry().getPackageUnits()) {
    System.out.print("Id : " + pu.getID());
    System.out.print(", State : " + pu.getState());
    System.out.print(", Type : " + pu.getType());
    System.out.println(", Original : " + pu.getOriginalType());
}

But this time, I get a NPE when I try to list again my registered packages (not when invoking putEPackage but rather when calling getType !) :
Id : http://application/2.0, State : PROXY, Type : LEGACY, Original : NATIVE
Id : http://eclipse.org/graphiti/mm, State : LOADED
...
java.lang.NullPointerException
    at org.eclipse.emf.cdo.common.model.CDOPackageTypeRegistry.lookup(CDOPackageTypeRegistry.java:105)
    at org.eclipse.emf.cdo.internal.common.model.CDOPackageUnitImpl.getType(CDOPackageUnitImpl.java:114)
...

Any idea why the missing packages are not registered like for the CDO Explorer and why I fail to force this registration ?

Regards,

Laurent
Re: [CDO] OCL query failing on a newly started CDO server... [message #1369691 is a reply to message #1369645] Tue, 20 May 2014 13:58 Go to previous messageGo to next message
Christian W. Damus is currently offline Christian W. Damus
Messages: 775
Registered: July 2009
Senior Member
Hi, Laurent,

Sorry, I didn't understand that your use case is re-starting a server
that already has content. I identified with a problem I had once, in
which the CDO server instance was entirely new and had no packages
registered because it contained no data. :-/

If a server-side view can't find the EPackages for objects that are
present in the repository when parsing OCL, I'm afraid I won't be of
much help.

One question: are these packages that you're having difficulty with
nested EPackages? (sub-packages contained within another package)
AFAIK, that should work in CDO (there had been problems, but they
should be fixed long since), but I'm not sure.

Which version of CDO are you using?

cW


On 2014-05-20 17:32:48 +0000, Laurent Le Moux said:

> Hi Christian,
>
> Thanks for your answer. I tried to add your statement in my cdo-server.xml:
>
> <initialPackage nsURI="http://eclipse.org/graphiti/mm"/>
> <initialPackage nsURI="http://eclipse.org/graphiti/mm/algorithms"/>
> <initialPackage nsURI="http://eclipse.org/graphiti/mm/algorithms/styles"/>
> <initialPackage nsURI="http://eclipse.org/graphiti/mm/pictograms"/>
>
>
> But the server then refuses to start with a 'JdbcSQLException: Unique
> index or primary key violation' message (see attached log).
>
> Moreover, when I execute my query, the repository is not empty. So I
> would not get an empty result back.
> But, as the server has just been restarted, it seems that the implicit
> EPackage loading you described does not take place.
>
> So, I had a look to the CDO Explorer package registry and it appears
> the Graphiti packages are correctly loaded (see attached screenshot):
>
>
>
> Whereas, when I add traces to list the registered packages in my
> application, only the first Graphiti package is registered !
>
> Id : http://application/2.0, State : PROXY, Type : LEGACY, Original : NATIVE
> Id : http://eclipse.org/graphiti/mm, State : PROXY, Type : LEGACY,
> Original : NATIVE
> Id : http://lemoux.fr/modeling/framework/commons/metadata/commit, State
> : PROXY, Type : LEGACY, Original : NATIVE
> Id :
> http://lemoux.fr/modeling/framework/commons/metadata/configuration,
> State : PROXY, Type : LEGACY, Original : NATIVE
> Id : http://repositorystructure/2.0, State : PROXY, Type : LEGACY,
> Original : NATIVE
> Id : http://service/2.0, State : PROXY, Type : LEGACY, Original : NATIVE
> Id : http://user/1.0, State : PROXY, Type : LEGACY, Original : NATIVE
> Id : http://www.eclipse.org/emf/2002/Ecore, State : PROXY, Type :
> LEGACY, Original : LEGACY
> Id : http://www.eclipse.org/emf/CDO/Eresource/4.0.0, State : PROXY,
> Type : NATIVE, Original : NATIVE
> Id : http://www.eclipse.org/emf/CDO/Etypes/4.0.0, State : PROXY, Type :
> NATIVE, Original : NATIVE
> Id : http://www.eclipse.org/emf/CDO/expressions/4.3.0, State : PROXY,
> Type : LEGACY, Original : NATIVE
> Id : http://www.eclipse.org/emf/CDO/security/4.1.0, State : PROXY, Type
> : LEGACY, Original : NATIVE
>
> I then tried again to register the 3 missing packages (like in Eike's
> StandaloneContainerExample in the CDO Wiki snippets) :
>
> // Register missing Graphiti packages
> session.getPackageRegistry().putEPackage(AlgorithmsPackage.eINSTANCE);
> session.getPackageRegistry().putEPackage(StylesPackage.eINSTANCE);
> session.getPackageRegistry().putEPackage(PictogramsPackage.eINSTANCE);
>
> // List registered packages
> for (CDOPackageUnit pu : session.getPackageRegistry().getPackageUnits()) {
> System.out.print("Id : " + pu.getID());
> System.out.print(", State : " + pu.getState());
> System.out.print(", Type : " + pu.getType());
> System.out.println(", Original : " + pu.getOriginalType());
> }
>
> But this time, I get a NPE when I try to list again my registered
> packages (not when invoking putEPackage but rather when calling getType
> !) :
>
> Id : http://application/2.0, State : PROXY, Type : LEGACY, Original : NATIVE
> Id : http://eclipse.org/graphiti/mm, State : LOADED
> ..
> java.lang.NullPointerException
> at
> org.eclipse.emf.cdo.common.model.CDOPackageTypeRegistry.lookup(CDOPackageTypeRegistry.java:105)
>
> at
> org.eclipse.emf.cdo.internal.common.model.CDOPackageUnitImpl.getType(CDOPackageUnitImpl.java:114)
>
> ..
>
> Any idea why the missing packages are not registered like for the CDO
> Explorer and why I fail to force this registration ?
>
> Regards,
>
> Laurent
> <image><image>
Re: [CDO] OCL query failing on a newly started CDO server... [message #1369870 is a reply to message #1369691] Tue, 20 May 2014 15:39 Go to previous messageGo to next message
Laurent Le Moux is currently offline Laurent Le Moux
Messages: 147
Registered: September 2011
Senior Member
Hi Christian,

The EPackages are indeed nested ones (Graphiti packages simply adapted to be CDO compliant). My guess would be that the former CDO problems you mention are not the cause if mine really has to do with registration and considering the fact that the packages seems to be correctly registered on CDO Explorer side.

That's the reason why I would like to know how to make sure the missing packages in application are properly registered ?

How is this handled by CDO Explorer ?

And how comes that putEPackage seems to fail without notice until I casually called getType and got a NPE ?

I use CDO 4.3...

Laurent
Re: [CDO] OCL query failing on a newly started CDO server... [message #1374576 is a reply to message #1369870] Thu, 22 May 2014 14:01 Go to previous messageGo to next message
Laurent Le Moux is currently offline Laurent Le Moux
Messages: 147
Registered: September 2011
Senior Member
Hi again,

After some more search, the problem seems not to be whether the inner Graphiti packages are registered or not because, once I opened a diagram, I can successfully run my OCL query and there's still only one package registered in my application CDO session.

But, I just noticed that this single registered Graphiti package is registered with the state LOADED whereas it has the state PROXY in the CDO Explorer.

Could that be the reason ? If yes, how can I change this ?

Regards,

Laurent
Re: [CDO] OCL query failing on a newly started CDO server... [message #1376006 is a reply to message #1374576] Fri, 23 May 2014 04:07 Go to previous messageGo to next message
Leonid Ripeynih is currently offline Leonid Ripeynih
Messages: 98
Registered: February 2012
Member
Hi, Laurent.

One way to work around you problem is to use EClass of you package as a context object for OCL query.
For example, this query will fail on cold (just restarted) CDO:

CDOQuery q = view.createQuery("ocl", "myPackage::MyClass.allInstances()");
System.out.println(q.getResult());


This, however, will work fine:

CDOQuery q = view.createQuery("ocl", "myPackage::MyClass.allInstances()", MyPackage.Literals.MY_CLASS);
System.out.println(q.getResult());


The correct fix, however, should probably include some fixes on OCL side. Root of a problem lies in
org.eclipse.ocl.ecore.EcoreEnvironment.findPackage(List<String>, Registry)
for (Object next : registry.values()) {
  if (next instanceof EPackage) {
    ...
  }
}	


On the 'cold' CDO server, package registry contains so called PackageDescriptors, which is a lazy-loading proxy of a EPackage. Of only OCL could concider them and load on-demand...



Re: [CDO] OCL query failing on a newly started CDO server... [message #1376080 is a reply to message #1376006] Fri, 23 May 2014 04:45 Go to previous messageGo to next message
Ed Willink is currently offline Ed Willink
Messages: 4035
Registered: July 2009
Senior Member
Hi

Hopefully for Mars we can migrate to the Pivot-based OCL that has an
extension allowing a quoted URI as the first qualifier.

'http://my.package'::MyClass.allInstances()

Regards

Ed Willink


On 23/05/2014 09:07, Leonid Ripeynih wrote:
> Hi, Laurent.
> One way to work around you problem is to use EClass of you package as
> a context object for OCL query.
> For example, this query will fail on cold (just restarted) CDO:
>
>
> CDOQuery q = view.createQuery("ocl",
> "myPackage::MyClass.allInstances()");
> System.out.println(q.getResult());
>
>
> This, however, will work fine:
>
>
> CDOQuery q = view.createQuery("ocl",
> "myPackage::MyClass.allInstances()", MyPackage.Literals.MY_CLASS);
> System.out.println(q.getResult());
>
>
> The correct fix, however, should probably include some fixes on OCL
> side. Root of a problem lies in
> org.eclipse.ocl.ecore.EcoreEnvironment.findPackage(List<String>,
> Registry)
> for (Object next : registry.values()) {
> if (next instanceof EPackage) {
> ...
> }
> }
>
>
> On the 'cold' CDO server, package registry contains so called
> PackageDescriptors, which is a lazy-loading proxy of a EPackage. Of
> only OCL could concider them and load on-demand...
>
>
>
Re: [CDO] OCL query failing on a newly started CDO server... [message #1383243 is a reply to message #1376080] Mon, 26 May 2014 05:18 Go to previous messageGo to next message
Laurent Le Moux is currently offline Laurent Le Moux
Messages: 147
Registered: September 2011
Senior Member
Hi Leonid & Ed,

Thank you both for your detailed answer. But I'm afraid I'm not yet out of it...

I tried the following :
// Dummy OCL query to ensure the Graphiti packages are loaded
String dummyGraphitiQuery = "mm::StyleContainer.allInstances()";
CDOQuery cqDummyGraphiti = transaction.createQuery("ocl", dummyGraphitiQuery, MmPackage.Literals.STYLE_CONTAINER);
cqDummyGraphiti.getResult();

// Look for all diagrams where the element appears
String diagramsQuery = "mm::pictograms::Diagram.allInstances()->select(d:mm::pictograms::Diagram | "
		+ "d.children.link.businessObjects->includes(self))";
CDOQuery cqDiagrams = transaction.createQuery("ocl", diagramsQuery, element.cdoID(), true);
final List<Diagram> diagrams = cqDiagrams.getResult(Diagram.class);

This works except in one situation where I now get the following exception :
org.eclipse.net4j.util.WrappedException: Problem executing OCL query: mm::pictograms::Diagram.allInstances()->select(d:mm::pictograms::Diagram | d.children.link.businessObjects->includes(self))
	at org.eclipse.net4j.util.WrappedException.wrap(WrappedException.java:44)
	at org.eclipse.emf.cdo.server.ocl.OCLQueryHandler.executeQuery(OCLQueryHandler.java:153)
	at org.eclipse.emf.cdo.internal.server.QueryManager$QueryContext.run(QueryManager.java:303)
	at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
	at java.util.concurrent.FutureTask.run(Unknown Source)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.Exception: OCL query evaluated to 'invalid'. Run with '-Dorg.eclipse.ocl.debug=true' and visit the log for failure details.
	at org.eclipse.emf.cdo.server.ocl.OCLQueryHandler.executeQuery(OCLQueryHandler.java:132)
	... 6 more


I actually have another query which purpose is - before I delete a 'service' element from my repository - to check that none of its 'operation' sub-elements is still referenced elsewhere in the repository by an 'application' element.

I'm also facing problems with this second query depending on whether it is executed on a cold server or not. The result - however - is different. Instead of getting an exception, I just get an empty 'application' list back when I shouldn't...

So, if I run this second query first on a cold server, it fails. And then, the first query also fails with the above exception.

I tried the same trick :
// Dummy OCL queries to ensure the Application, Service and Operation packages are loaded
String dummyApplicationQuery = "applicationv2::Application.allInstances()";
CDOQuery cqDummyApplication = transaction.createQuery("ocl", dummyApplicationQuery, Applicationv2Package.Literals.APPLICATION);
cqDummyApplication.getResult();

String dummyServiceQuery = "servicev2::Service.allInstances()";
CDOQuery cqDummyService = transaction.createQuery("ocl", dummyServiceQuery, Servicev2Package.Literals.SERVICE);
cqDummyService.getResult();

String dummyOperationQuery = "servicev2::Operation.allInstances()";
CDOQuery cqDummyOperation = transaction.createQuery("ocl", dummyOperationQuery, Servicev2Package.Literals.OPERATION);
cqDummyOperation.getResult();

// Use an OCL query to find any application invoking any deleted service operation
String appsQuery = "applicationv2::Application.allInstances()->select(a:applicationv2::Application|not a.invokes->intersection(self.defines)->isEmpty())";
CDOQuery cqApps = transaction.createQuery("ocl", appsQuery, ((Service)element).cdoID(), false);
List<Application> clientApps = cqApps.getResult(Application.class);

The three dummy queries are apparently returning the expected results (I checked each returned list size).

But I still get an unexpected empty result back and I still 'disturbs' the other query if run first...

Any idea why ?

Regards,

Laurent
Re: [CDO] OCL query failing on a newly started CDO server... [message #1383397 is a reply to message #1383243] Mon, 26 May 2014 06:45 Go to previous messageGo to next message
Ed Willink is currently offline Ed Willink
Messages: 4035
Registered: July 2009
Senior Member
Hi Laurent

It looks as if you have a genuine problem that I should look at. Maybe
it's OCL, maybe CDO.OCL may be bad user init.

Whatever, since I've only used CDO when investigating CDO/OCL queries,
please provide an easy to use repro with clear instructions on how to
reproduce your problem and attach it to a CDO Bugzilla.

I'm kind of busy with Luna RC releases at present so I cannot promise to
look at it till late next week at the earliest.

Regards

Ed Willink

On 26/05/2014 10:18, Laurent Le Moux wrote:
> Hi Leonid & Ed,
>
> Thank you both for your detailed answer. But I'm afraid I'm not yet
> out of it...
>
> I tried the following :
>
> // Dummy OCL query to ensure the Graphiti packages are loaded
> String dummyGraphitiQuery = "mm::StyleContainer.allInstances()";
> CDOQuery cqDummyGraphiti = transaction.createQuery("ocl",
> dummyGraphitiQuery, MmPackage.Literals.STYLE_CONTAINER);
> cqDummyGraphiti.getResult();
>
> // Look for all diagrams where the element appears
> String diagramsQuery =
> "mm::pictograms::Diagram.allInstances()->select(d:mm::pictograms::Diagram
> | "
> + "d.children.link.businessObjects->includes(self))";
> CDOQuery cqDiagrams = transaction.createQuery("ocl", diagramsQuery,
> element.cdoID(), true);
> final List<Diagram> diagrams = cqDiagrams.getResult(Diagram.class);
>
> This works except in one situation where I now get the following
> exception :
>
> org.eclipse.net4j.util.WrappedException: Problem executing OCL query:
> mm::pictograms::Diagram.allInstances()->select(d:mm::pictograms::Diagram
> | d.children.link.businessObjects->includes(self))
> at
> org.eclipse.net4j.util.WrappedException.wrap(WrappedException.java:44)
> at
> org.eclipse.emf.cdo.server.ocl.OCLQueryHandler.executeQuery(OCLQueryHandler.java:153)
> at
> org.eclipse.emf.cdo.internal.server.QueryManager$QueryContext.run(QueryManager.java:303)
> at java.util.concurrent.Executors$RunnableAdapter.call(Unknown
> Source)
> at java.util.concurrent.FutureTask.run(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
> Caused by: java.lang.Exception: OCL query evaluated to 'invalid'. Run
> with '-Dorg.eclipse.ocl.debug=true' and visit the log for failure
> details.
> at
> org.eclipse.emf.cdo.server.ocl.OCLQueryHandler.executeQuery(OCLQueryHandler.java:132)
> ... 6 more
>
>
> I actually have another query which purpose is - before I delete a
> 'service' element from my repository - to check that none of its
> 'operation' sub-elements is still referenced elsewhere in the
> repository by an 'application' element.
>
> I'm also facing problems with this second query depending on whether
> it is executed on a cold server or not. The result - however - is
> different. Instead of getting an exception, I just get an empty
> 'application' list back when I shouldn't...
>
> So, if I run this second query first on a cold server, it fails. And
> then, the first query also fails with the above exception.
>
> I tried the same trick :
>
> // Dummy OCL queries to ensure the Application, Service and Operation
> packages are loaded
> String dummyApplicationQuery =
> "applicationv2::Application.allInstances()";
> CDOQuery cqDummyApplication = transaction.createQuery("ocl",
> dummyApplicationQuery, Applicationv2Package.Literals.APPLICATION);
> cqDummyApplication.getResult();
>
> String dummyServiceQuery = "servicev2::Service.allInstances()";
> CDOQuery cqDummyService = transaction.createQuery("ocl",
> dummyServiceQuery, Servicev2Package.Literals.SERVICE);
> cqDummyService.getResult();
>
> String dummyOperationQuery = "servicev2::Operation.allInstances()";
> CDOQuery cqDummyOperation = transaction.createQuery("ocl",
> dummyOperationQuery, Servicev2Package.Literals.OPERATION);
> cqDummyOperation.getResult();
>
> // Use an OCL query to find any application invoking any deleted
> service operation
> String appsQuery =
> "applicationv2::Application.allInstances()->select(a:applicationv2::Application|not
> a.invokes->intersection(self.defines)->isEmpty())";
> CDOQuery cqApps = transaction.createQuery("ocl", appsQuery,
> ((Service)element).cdoID(), false);
> List<Application> clientApps = cqApps.getResult(Application.class);
>
> The three dummy queries are apparently returning the expected results
> (I checked each returned list size).
>
> But I still get an unexpected empty result back and I still 'disturbs'
> the other query if run first...
>
> Any idea why ?
>
> Regards,
>
> Laurent
Re: [CDO] OCL query failing on a newly started CDO server... [message #1383875 is a reply to message #1383397] Mon, 26 May 2014 11:53 Go to previous message
Laurent Le Moux is currently offline Laurent Le Moux
Messages: 147
Registered: September 2011
Senior Member
Hi Ed,

Considering that it is not so easy to build a test using Graphiti packages, there is no direct dependency (no cross reference) with my model and Leonid has apparently already identified the problem origin, I just built a test for my second query where Leonid's tip is unfortunately not working :

https://bugs.eclipse.org/bugs/show_bug.cgi?id=435807

You'll see that, in the test, the problem shows up differently...

Regards,

Laurent
Previous Topic:[Xcore] Xcore for Xtext 2.6?
Next Topic:ValidationMarkerManager marks objects with partly matching URI
Goto Forum:
  


Current Time: Thu Aug 28 11:19:55 EDT 2014

Powered by FUDForum. Page generated in 0.02321 seconds