Home » Modeling » EMF » [CDO] OCL query fails with an SQL statement already in cache
[CDO] OCL query fails with an SQL statement already in cache [message #1098838] |
Sat, 31 August 2013 19:37  |
Eclipse User |
|
|
|
Hi,
Having got past the problem of my OCL query failing because an EClass
is not mapped (I rebased to latest git master today), now I get a new
kind of failure.
My more elaborate query today attempts to narrow the scope of matched
objects to those that are in some resource path prefix. For example,
NamedElement.allInstances()->select(e |
e.name = 'Foo' and
e.oclAsType(ecore::EObject).eResource().oclAsType(eresource::CDOResource).path.startsWith('/cdamus/')
)
(I have to cast a NamedElement to EObject because although NamedElement
is an indirect subtype of ecore::EModelElement, Ecore removed EObject
from the supertypes of EModelElement some releases ago)
The exception that I get in the log seems to show that my OCL query
bombed on an IllegalStateException indicating that an SQL prepared
statement is already in the cache. I don't know the DB layer at all ...
cW
-------- 8< --------
!ENTRY org.eclipse.net4j.db 4 0 2013-08-31 15:22:47.251
!MESSAGE SELECT CDO_CLASS FROM CDO_OBJECTS WHERE CDO_ID=? already in cache
!STACK 0
java.lang.IllegalStateException: SELECT CDO_CLASS FROM CDO_OBJECTS
WHERE CDO_ID=
? already in cache
at
org.eclipse.net4j.internal.db.DBConnection.releasePreparedStatement(DBConnec
tion.java:172)
at
org.eclipse.net4j.internal.db.DBPreparedStatement.close(DBPreparedStatement.
java:95)
at org.eclipse.net4j.db.DBUtil.close(DBUtil.java:425)
at
org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.ObjectTypeTable.ge
tObjectType(ObjectTypeTable.java:99)
at
org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.DelegatingObjectTy
peMapper.getObjectType(DelegatingObjectTypeMapper.java:60)
at
org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.AbstractHorizontal
MappingStrategy.readObjectType(AbstractHorizontalMappingStrategy.java:82)
at
org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.HorizontalMappingS
trategy.readObjectType(HorizontalMappingStrategy.java:194)
at
org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.readObjectType(DBStor
eAccessor.java:205)
at
org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.getObjectType(DBStore
Accessor.java:222)
at
org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.readRevisionByVersion
(DBStoreAccessor.java:270)
at
org.eclipse.emf.cdo.internal.server.Repository.loadRevisionByVersion(Reposit
ory.java:578)
at
org.eclipse.emf.cdo.internal.common.revision.CDORevisionManagerImpl.getRevis
ionByVersion(CDORevisionManagerImpl.java:252)
at
org.eclipse.emf.cdo.internal.common.revision.CDORevisionManagerImpl.getRevis
ionByVersion(CDORevisionManagerImpl.java:1)
at
org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.HorizontalBranchin
gClassMapping.handleRevisions(HorizontalBranchingClassMapping.java:867)
at
org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappingStrategy.handl
eRevisions(AbstractMappingStrategy.java:220)
at
org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.HorizontalMappingS
trategy.handleRevisions(HorizontalMappingStrategy.java:210)
at
org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.handleRevisions(DBSto
reAccessor.java:1084)
at
org.eclipse.emf.cdo.server.ocl.CDOExtentCreator.handleRevisions(CDOExtentCre
ator.java:173)
at
org.eclipse.emf.cdo.server.ocl.CDOExtentCreator.createExtent(CDOExtentCreato
r.java:160)
at
org.eclipse.emf.cdo.server.ocl.CDOExtentCreator$Lazy$1$1.handlePersistentSta
te(CDOExtentCreator.java:318)
at
org.eclipse.emf.cdo.server.ocl.CDOExtentCreator$Lazy$1$1.run(CDOExtentCreato
r.java:262)
|
|
|
Re: [CDO] OCL query fails with an SQL statement already in cache [message #1098845 is a reply to message #1098838] |
Sat, 31 August 2013 19:54   |
Eclipse User |
|
|
|
Actually, the SQL-statement-already-in-cache thing was a red herring.
The problem is that when OCL accesses the 'path' feature of a
CDOResource, eGet with the 'path' EAttribute returns null, whereas
invocation (in the debugger) of the CDOResourceNode::getPath() accessor
method returns the resource's correct path.
So, Ecore reflection to get CDOResourceNode::path doesn't work, but
CDOResourceNode::getPath() does.
cW
On 2013-08-31 19:37:21 +0000, Christian W. Damus said:
> Hi,
>
> Having got past the problem of my OCL query failing because an EClass
> is not mapped (I rebased to latest git master today), now I get a new
> kind of failure.
>
> My more elaborate query today attempts to narrow the scope of matched
> objects to those that are in some resource path prefix. For example,
>
> NamedElement.allInstances()->select(e |
> e.name = 'Foo' and
>
> e.oclAsType(ecore::EObject).eResource().oclAsType(eresource::CDOResource).path.startsWith('/cdamus/')
> )
>
> (I have to cast a NamedElement to EObject because although NamedElement
> is an indirect subtype of ecore::EModelElement, Ecore removed EObject
> from the supertypes of EModelElement some releases ago)
>
> The exception that I get in the log seems to show that my OCL query
> bombed on an IllegalStateException indicating that an SQL prepared
> statement is already in the cache. I don't know the DB layer at all ...
>
> cW
>
>
> -------- 8< --------
>
> !ENTRY org.eclipse.net4j.db 4 0 2013-08-31 15:22:47.251
> !MESSAGE SELECT CDO_CLASS FROM CDO_OBJECTS WHERE CDO_ID=? already in cache
> !STACK 0
> java.lang.IllegalStateException: SELECT CDO_CLASS FROM CDO_OBJECTS
> WHERE CDO_ID=
> ? already in cache
> at
> org.eclipse.net4j.internal.db.DBConnection.releasePreparedStatement(DBConnec
>
> tion.java:172)
> at
> org.eclipse.net4j.internal.db.DBPreparedStatement.close(DBPreparedStatement.
>
> java:95)
> at org.eclipse.net4j.db.DBUtil.close(DBUtil.java:425)
> at
> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.ObjectTypeTable.ge
>
> tObjectType(ObjectTypeTable.java:99)
> at
> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.DelegatingObjectTy
>
> peMapper.getObjectType(DelegatingObjectTypeMapper.java:60)
> at
> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.AbstractHorizontal
>
> MappingStrategy.readObjectType(AbstractHorizontalMappingStrategy.java:82)
> at
> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.HorizontalMappingS
>
> trategy.readObjectType(HorizontalMappingStrategy.java:194)
> at
> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.readObjectType(DBStor
>
> eAccessor.java:205)
> at
> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.getObjectType(DBStore
>
> Accessor.java:222)
> at
> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.readRevisionByVersion
>
> (DBStoreAccessor.java:270)
> at
> org.eclipse.emf.cdo.internal.server.Repository.loadRevisionByVersion(Reposit
>
> ory.java:578)
> at
> org.eclipse.emf.cdo.internal.common.revision.CDORevisionManagerImpl.getRevis
>
> ionByVersion(CDORevisionManagerImpl.java:252)
> at
> org.eclipse.emf.cdo.internal.common.revision.CDORevisionManagerImpl.getRevis
>
> ionByVersion(CDORevisionManagerImpl.java:1)
> at
> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.HorizontalBranchin
>
> gClassMapping.handleRevisions(HorizontalBranchingClassMapping.java:867)
> at
> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappingStrategy.handl
>
> eRevisions(AbstractMappingStrategy.java:220)
> at
> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.HorizontalMappingS
>
> trategy.handleRevisions(HorizontalMappingStrategy.java:210)
> at
> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.handleRevisions(DBSto
>
> reAccessor.java:1084)
> at
> org.eclipse.emf.cdo.server.ocl.CDOExtentCreator.handleRevisions(CDOExtentCre
>
> ator.java:173)
> at
> org.eclipse.emf.cdo.server.ocl.CDOExtentCreator.createExtent(CDOExtentCreato
>
> r.java:160)
> at
> org.eclipse.emf.cdo.server.ocl.CDOExtentCreator$Lazy$1$1.handlePersistentSta
>
> te(CDOExtentCreator.java:318)
> at
> org.eclipse.emf.cdo.server.ocl.CDOExtentCreator$Lazy$1$1.run(CDOExtentCreato
>
> r.java:262)
|
|
|
Re: [CDO] OCL query fails with an SQL statement already in cache [message #1098853 is a reply to message #1098845] |
Sat, 31 August 2013 20:09   |
Eclipse User |
|
|
|
The CDOResourceNode::path feature is transient and derived from folder
and name.
Adding the following to CDOResourceNodeImpl fixes the problem. Is
there a better way?
cW
-------- 8< --------
@Override
public Object eGet(int featureID, boolean resolve, boolean coreType)
{
switch (featureID)
{
case EresourcePackage.CDO_RESOURCE_NODE__PATH:
return getPath();
default:
return super.eGet(featureID, resolve, coreType);
}
}
@Override
public void eSet(int featureID, Object newValue)
{
switch (featureID)
{
case EresourcePackage.CDO_RESOURCE_NODE__PATH:
setPath((String)newValue);
break;
default:
super.eSet(featureID, newValue);
break;
}
}
On 2013-08-31 19:54:49 +0000, Christian W. Damus said:
> Actually, the SQL-statement-already-in-cache thing was a red herring.
>
> The problem is that when OCL accesses the 'path' feature of a
> CDOResource, eGet with the 'path' EAttribute returns null, whereas
> invocation (in the debugger) of the CDOResourceNode::getPath() accessor
> method returns the resource's correct path.
>
> So, Ecore reflection to get CDOResourceNode::path doesn't work, but
> CDOResourceNode::getPath() does.
>
> cW
>
>
> On 2013-08-31 19:37:21 +0000, Christian W. Damus said:
>
>> Hi,
>>
>> Having got past the problem of my OCL query failing because an EClass
>> is not mapped (I rebased to latest git master today), now I get a new
>> kind of failure.
>>
>> My more elaborate query today attempts to narrow the scope of matched
>> objects to those that are in some resource path prefix. For example,
>>
>> NamedElement.allInstances()->select(e |
>> e.name = 'Foo' and
>>
>> e.oclAsType(ecore::EObject).eResource().oclAsType(eresource::CDOResource).path.startsWith('/cdamus/')
>> )
>>
>> (I have to cast a NamedElement to EObject because although NamedElement
>> is an indirect subtype of ecore::EModelElement, Ecore removed EObject
>> from the supertypes of EModelElement some releases ago)
>>
>> The exception that I get in the log seems to show that my OCL query
>> bombed on an IllegalStateException indicating that an SQL prepared
>> statement is already in the cache. I don't know the DB layer at all ...
>>
>> cW
>>
>>
>> -------- 8< --------
>>
>> !ENTRY org.eclipse.net4j.db 4 0 2013-08-31 15:22:47.251
>> !MESSAGE SELECT CDO_CLASS FROM CDO_OBJECTS WHERE CDO_ID=? already in cache
>> !STACK 0
>> java.lang.IllegalStateException: SELECT CDO_CLASS FROM CDO_OBJECTS
>> WHERE CDO_ID=
>> ? already in cache
>> at
>> org.eclipse.net4j.internal.db.DBConnection.releasePreparedStatement(DBConnec
>>
>> tion.java:172)
>> at
>> org.eclipse.net4j.internal.db.DBPreparedStatement.close(DBPreparedStatement.
>>
>> java:95)
>> at org.eclipse.net4j.db.DBUtil.close(DBUtil.java:425)
>> at
>> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.ObjectTypeTable.ge
>>
>> tObjectType(ObjectTypeTable.java:99)
>> at
>> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.DelegatingObjectTy
>>
>> peMapper.getObjectType(DelegatingObjectTypeMapper.java:60)
>> at
>> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.AbstractHorizontal
>>
>> MappingStrategy.readObjectType(AbstractHorizontalMappingStrategy.java:82)
>> at
>> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.HorizontalMappingS
>>
>> trategy.readObjectType(HorizontalMappingStrategy.java:194)
>> at
>> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.readObjectType(DBStor
>>
>> eAccessor.java:205)
>> at
>> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.getObjectType(DBStore
>>
>> Accessor.java:222)
>> at
>> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.readRevisionByVersion
>>
>> (DBStoreAccessor.java:270)
>> at
>> org.eclipse.emf.cdo.internal.server.Repository.loadRevisionByVersion(Reposit
>>
>> ory.java:578)
>> at
>> org.eclipse.emf.cdo.internal.common.revision.CDORevisionManagerImpl.getRevis
>>
>> ionByVersion(CDORevisionManagerImpl.java:252)
>> at
>> org.eclipse.emf.cdo.internal.common.revision.CDORevisionManagerImpl.getRevis
>>
>> ionByVersion(CDORevisionManagerImpl.java:1)
>> at
>> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.HorizontalBranchin
>>
>> gClassMapping.handleRevisions(HorizontalBranchingClassMapping.java:867)
>> at
>> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappingStrategy.handl
>>
>> eRevisions(AbstractMappingStrategy.java:220)
>> at
>> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.HorizontalMappingS
>>
>> trategy.handleRevisions(HorizontalMappingStrategy.java:210)
>> at
>> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.handleRevisions(DBSto
>>
>> reAccessor.java:1084)
>> at
>> org.eclipse.emf.cdo.server.ocl.CDOExtentCreator.handleRevisions(CDOExtentCre
>>
>> ator.java:173)
>> at
>> org.eclipse.emf.cdo.server.ocl.CDOExtentCreator.createExtent(CDOExtentCreato
>>
>> r.java:160)
>> at
>> org.eclipse.emf.cdo.server.ocl.CDOExtentCreator$Lazy$1$1.handlePersistentSta
>>
>> te(CDOExtentCreator.java:318)
>> at
>> org.eclipse.emf.cdo.server.ocl.CDOExtentCreator$Lazy$1$1.run(CDOExtentCreato
>>
>> r.java:262)
|
|
|
Re: [CDO] OCL query fails with an SQL statement already in cache [message #1099109 is a reply to message #1098853] |
Sun, 01 September 2013 06:04   |
Eclipse User |
|
|
|
Am 31.08.2013 22:09, schrieb Christian W. Damus:
> The CDOResourceNode::path feature is transient and derived from folder and name.
>
> Adding the following to CDOResourceNodeImpl fixes the problem. Is there a better way?
I don't think so. I wonder why the EMF generator didn't generate these eGet/eSet methods. I've added another pair for
CDOResource::uri.
416298: CDOResourceNodes do not support reflective access to derived path attribute
https://bugs.eclipse.org/bugs/show_bug.cgi?id=416298
https://git.eclipse.org/r/#/c/16022/
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
>
> cW
>
> -------- 8< --------
>
>
> @Override
> public Object eGet(int featureID, boolean resolve, boolean coreType)
> {
> switch (featureID)
> {
> case EresourcePackage.CDO_RESOURCE_NODE__PATH:
> return getPath();
> default:
> return super.eGet(featureID, resolve, coreType);
> }
> }
>
> @Override
> public void eSet(int featureID, Object newValue)
> {
> switch (featureID)
> {
> case EresourcePackage.CDO_RESOURCE_NODE__PATH:
> setPath((String)newValue);
> break;
> default:
> super.eSet(featureID, newValue);
> break;
> }
> }
>
>
> On 2013-08-31 19:54:49 +0000, Christian W. Damus said:
>
>> Actually, the SQL-statement-already-in-cache thing was a red herring.
>>
>> The problem is that when OCL accesses the 'path' feature of a CDOResource, eGet with the 'path' EAttribute returns
>> null, whereas invocation (in the debugger) of the CDOResourceNode::getPath() accessor method returns the resource's
>> correct path.
>>
>> So, Ecore reflection to get CDOResourceNode::path doesn't work, but CDOResourceNode::getPath() does.
>>
>> cW
>>
>>
>> On 2013-08-31 19:37:21 +0000, Christian W. Damus said:
>>
>>> Hi,
>>>
>>> Having got past the problem of my OCL query failing because an EClass is not mapped (I rebased to latest git master
>>> today), now I get a new kind of failure.
>>>
>>> My more elaborate query today attempts to narrow the scope of matched objects to those that are in some resource
>>> path prefix. For example,
>>>
>>> NamedElement.allInstances()->select(e |
>>> e.name = 'Foo' and
>>>
>>> e.oclAsType(ecore::EObject).eResource().oclAsType(eresource::CDOResource).path.startsWith('/cdamus/') )
>>>
>>> (I have to cast a NamedElement to EObject because although NamedElement is an indirect subtype of
>>> ecore::EModelElement, Ecore removed EObject from the supertypes of EModelElement some releases ago)
>>>
>>> The exception that I get in the log seems to show that my OCL query bombed on an IllegalStateException indicating
>>> that an SQL prepared statement is already in the cache. I don't know the DB layer at all ...
>>>
>>> cW
>>>
>>>
>>> -------- 8< --------
>>>
>>> !ENTRY org.eclipse.net4j.db 4 0 2013-08-31 15:22:47.251
>>> !MESSAGE SELECT CDO_CLASS FROM CDO_OBJECTS WHERE CDO_ID=? already in cache
>>> !STACK 0
>>> java.lang.IllegalStateException: SELECT CDO_CLASS FROM CDO_OBJECTS WHERE CDO_ID=
>>> ? already in cache
>>> at org.eclipse.net4j.internal.db.DBConnection.releasePreparedStatement(DBConnec
>>> tion.java:172)
>>> at org.eclipse.net4j.internal.db.DBPreparedStatement.close(DBPreparedStatement.
>>> java:95)
>>> at org.eclipse.net4j.db.DBUtil.close(DBUtil.java:425)
>>> at org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.ObjectTypeTable.ge
>>> tObjectType(ObjectTypeTable.java:99)
>>> at org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.DelegatingObjectTy
>>> peMapper.getObjectType(DelegatingObjectTypeMapper.java:60)
>>> at org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.AbstractHorizontal
>>> MappingStrategy.readObjectType(AbstractHorizontalMappingStrategy.java:82)
>>> at org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.HorizontalMappingS
>>> trategy.readObjectType(HorizontalMappingStrategy.java:194)
>>> at org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.readObjectType(DBStor
>>> eAccessor.java:205)
>>> at org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.getObjectType(DBStore
>>> Accessor.java:222)
>>> at org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.readRevisionByVersion
>>> (DBStoreAccessor.java:270)
>>> at org.eclipse.emf.cdo.internal.server.Repository.loadRevisionByVersion(Reposit
>>> ory.java:578)
>>> at org.eclipse.emf.cdo.internal.common.revision.CDORevisionManagerImpl.getRevis
>>> ionByVersion(CDORevisionManagerImpl.java:252)
>>> at org.eclipse.emf.cdo.internal.common.revision.CDORevisionManagerImpl.getRevis
>>> ionByVersion(CDORevisionManagerImpl.java:1)
>>> at org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.HorizontalBranchin
>>> gClassMapping.handleRevisions(HorizontalBranchingClassMapping.java:867)
>>> at org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappingStrategy.handl
>>> eRevisions(AbstractMappingStrategy.java:220)
>>> at org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.HorizontalMappingS
>>> trategy.handleRevisions(HorizontalMappingStrategy.java:210)
>>> at org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.handleRevisions(DBSto
>>> reAccessor.java:1084)
>>> at org.eclipse.emf.cdo.server.ocl.CDOExtentCreator.handleRevisions(CDOExtentCre
>>> ator.java:173)
>>> at org.eclipse.emf.cdo.server.ocl.CDOExtentCreator.createExtent(CDOExtentCreato
>>> r.java:160)
>>> at org.eclipse.emf.cdo.server.ocl.CDOExtentCreator$Lazy$1$1.handlePersistentSta
>>> te(CDOExtentCreator.java:318)
>>> at org.eclipse.emf.cdo.server.ocl.CDOExtentCreator$Lazy$1$1.run(CDOExtentCreato
>>> r.java:262)
>
>
|
|
|
Re: [CDO] OCL query fails with an SQL statement already in cache [message #1436877 is a reply to message #1099109] |
Fri, 03 October 2014 14:50   |
Eclipse User |
|
|
|
Hi Christian and Eike,
Sorry to bring this post on top of the list again...
I'm facing a strange problem with OCL queries for a couple of months now.
I'm using CDO 4.3 shipped with Eclipse Modeling Luna 4.4.0.
I'm basically using the following three queries :
applicationv2::Application.allInstances()->select(a:applicationv2::Application|not a.invokes->intersection(self.defines)->isEmpty())
mm::pictograms::PictogramLink.allInstances()->select(pl:mm::pictograms::PictogramLink|pl.businessObjects->includes(self))
mm::pictograms::Diagram.allInstances()->select(d:mm::pictograms::Diagram | d.children.link.businessObjects->includes(self))
The first one is ok.
The second and third ones are querying the Graphiti model and fail or not, depending on how they are executed.
Starting from a "cold" CDO server (that is a non-empty repository that I just restarted), these queries fail when executed as first thing.
Whereas they run fine when executed after that Graphiti diagrams stored in CDO have been loaded in my RCP application editor.
I either get the same message a Christian on the server side with query n°2 :
!ENTRY org.eclipse.net4j.db 4 0 2014-10-03 14:42:16.279
!MESSAGE SELECT CDO_CLASS FROM CDO_OBJECTS WHERE CDO_ID=? already in cache
!STACK 0
java.lang.IllegalStateException: SELECT CDO_CLASS FROM CDO_OBJECTS WHERE CDO_ID=? already in cache
...
Or the following one, on the client side with query n°3 :
java.lang.RuntimeException: org.eclipse.net4j.util.WrappedException: Problem executing OCL query: mm::pictograms::Diagram.allInstances()->select(d:mm::pictograms::Diagram | d.children.link.businessObjects->includes(self))
...
Caused by: org.eclipse.ocl.SemanticException: Unknown type ([mm, pictograms, Diagram])
at org.eclipse.ocl.util.OCLUtil.checkForErrors(OCLUtil.java:352)
at org.eclipse.ocl.util.OCLUtil.checkForErrors(OCLUtil.java:322)
at org.eclipse.ocl.internal.helper.HelperUtil.checkForErrors(HelperUtil.java:512)
at org.eclipse.ocl.internal.helper.HelperUtil.parseQuery(HelperUtil.java:159)
at org.eclipse.ocl.internal.helper.OCLHelperImpl.createQuery(OCLHelperImpl.java:170)
at org.eclipse.emf.cdo.server.ocl.OCLQueryHandler.createQuery(OCLQueryHandler.java:230)
...
Christian already had a look in another post as well as Ed Willink on the OCL side :
http://www.eclipse.org/forums/index.php/t/760318/
Ed asked me to open the following bug report but I could unfortunetaly not help him much to reproduce the problem :
https://bugs.eclipse.org/bugs/show_bug.cgi?id=435807
I hope one of you can help because I can not figure out what to do...
Kind regards,
Laurent
|
|
|
Re: [CDO] OCL query fails with an SQL statement already in cache [message #1438188 is a reply to message #1436877] |
Sun, 05 October 2014 17:23   |
Eclipse User |
|
|
|
Hi
I can imagine two possible things may be contributing.
The domain of allInstances() is undefined. The LazyExtentMap for the
Ecore OCL in use by CDO takes a Resource-based view, but CDO may have a
different derivation. A warm CDO may have moved from one Resource to
another and perhaps the ExtentMap is stale. (The Pivot OCL takes a
ResourceSet-based view.)
Unreasonable messages that EClasses cannot be found are often due to
metamodel schizophrenia; you are using the EClass loaded in one model
while the tooling is using another. A warm CDO may have reloaded one
model leaving something stale. (The Pivot OCL's ProjectMap reuses
already loaded models rather than creating rivals.) If the failure
occurs on a cold CDO you are probably loading one model as http:/... (ie
a Java code generated mdel) and another as platform:/resource/...
If you are really determined you can create a third load for
platform:/plugin/... with even more variants if URI normalisation
malfunctions.
For all of the above, a log of Resource loading and unloading, and a log
of eContainer changes on EClasses named "Diagram" may provide some
insight; instrument eBasicSetContainer.
Regards
Ed Willink
On 03/10/2014 15:50, Laurent Le Moux wrote:
> Hi Christian and Eike,
>
> Sorry to bring this post on top of the list again...
> I'm facing a strange problem with OCL queries for a couple of months now.
> I'm using CDO 4.3 shipped with Eclipse Modeling Luna 4.4.0.
>
> I'm basically using the following three queries :
>
>
> applicationv2::Application.allInstances()->select(a:applicationv2::Application|not
> a.invokes->intersection(self.defines)->isEmpty())
>
>
>
> mm::pictograms::PictogramLink.allInstances()->select(pl:mm::pictograms::PictogramLink|pl.businessObjects->includes(self))
>
>
>
>
> mm::pictograms::Diagram.allInstances()->select(d:mm::pictograms::Diagram
> | d.children.link.businessObjects->includes(self))
>
>
> The first one is ok.
>
> The second and third ones are querying the Graphiti model and fail or
> not, depending on how they are executed.
>
> Starting from a "cold" CDO server (that is a non-empty repository that I
> just restarted), these queries fail when executed as first thing.
>
> Whereas they run fine when executed after that Graphiti diagrams stored
> in CDO have been loaded in my RCP application editor.
>
> I either get the same message a Christian on the server side with query
> n°2 :
>
>
> !ENTRY org.eclipse.net4j.db 4 0 2014-10-03 14:42:16.279
> !MESSAGE SELECT CDO_CLASS FROM CDO_OBJECTS WHERE CDO_ID=? already in cache
> !STACK 0
> java.lang.IllegalStateException: SELECT CDO_CLASS FROM CDO_OBJECTS WHERE
> CDO_ID=? already in cache
> ..
>
>
> Or the following one, on the client side with query n°3 :
>
>
> java.lang.RuntimeException: org.eclipse.net4j.util.WrappedException:
> Problem executing OCL query:
> mm::pictograms::Diagram.allInstances()->select(d:mm::pictograms::Diagram
> | d.children.link.businessObjects->includes(self))
> ..
> Caused by: org.eclipse.ocl.SemanticException: Unknown type ([mm,
> pictograms, Diagram])
> at org.eclipse.ocl.util.OCLUtil.checkForErrors(OCLUtil.java:352)
> at org.eclipse.ocl.util.OCLUtil.checkForErrors(OCLUtil.java:322)
> at
> org.eclipse.ocl.internal.helper.HelperUtil.checkForErrors(HelperUtil.java:512)
>
> at
> org.eclipse.ocl.internal.helper.HelperUtil.parseQuery(HelperUtil.java:159)
> at
> org.eclipse.ocl.internal.helper.OCLHelperImpl.createQuery(OCLHelperImpl.java:170)
>
> at
> org.eclipse.emf.cdo.server.ocl.OCLQueryHandler.createQuery(OCLQueryHandler.java:230)
>
> ..
>
>
> Christian already had a look in another post as well as Ed Willink on
> the OCL side :
>
> http://www.eclipse.org/forums/index.php/t/760318/
>
> Ed asked me to open the following bug report but I could unfortunetaly
> not help him much to reproduce the problem :
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=435807
>
> I hope one of you can help because I can not figure out what to do...
>
> Kind regards,
>
> Laurent
|
|
|
Re: [CDO] OCL query fails with an SQL statement already in cache [message #1439848 is a reply to message #1438188] |
Tue, 07 October 2014 15:40   |
Eclipse User |
|
|
|
Hi Ed,
What do you mean by "The domain of allInstances() is undefined" ? What's missing in my query ? Is the "mm::pictograms::Diagram" prefix not enough in mm::pictograms::Diagram.allInstances() ?
Concerning the potential "metamodel schizophrenia", you'll find attached my ecore models as well as the Graphiti one. Does it mean there's something wrong with their Ns URI ?
Concerning the log, I would like to provide you with all necessary details but I don't understand what to do. What do you mean by "instrument eBasicSetContainer" ? I found no eBasicSetContainer method in the EMF generated code or in CDO API...
Kind regards,
Laurent
Attachment: model.zip
(Size: 9.22KB, Downloaded 141 times)
|
|
|
Re: [CDO] OCL query fails with an SQL statement already in cache [message #1439895 is a reply to message #1439848] |
Tue, 07 October 2014 16:46   |
Eclipse User |
|
|
|
Hi
Answers in line
On 07/10/2014 16:40, Laurent Le Moux wrote:
> Hi Ed,
>
> What do you mean by "The domain of allInstances() is undefined" ?
Not defined in the OCL specification.
> What's missing in my query ? Is the "mm::pictograms::Diagram" prefix not enough in mm::pictograms::Diagram.allInstances() ?
>
> Concerning the potential "metamodel schizophrenia", you'll find attached my ecore models as well as the Graphiti one. Does it mean there's something wrong with their Ns URI ?
Metamodel schizophrenia is nothing to do with the model, it is to do
with allowing the model to be loaded more than once. Hence my
recommendation to instrument resource loading.
Consider an analogy.
Go to your bank and get a 10 dollar note.
Then go and get another one.
They will not be the same; they have different serial numbers.
Rather similar to a model repository; unless you take care, you get
another copy of an EClass which is not the same; it has a different
object identity and and so it fails to satisfy type conformance tests.
Even more brutal, see what the Java result of
new Double(1.0).equals(new Double(1.0)) is.
> Concerning the log, I would like to provide you with all necessary details but I don't understand what to do. What do you mean by "instrument eBasicSetContainer" ? I found no eBasicSetContainer method in the EMF generated code or in CDO API...
BasicEObjectImpl.eBasicSetContainer(InternalEObject newContainer, int
newContainerFeatureID)
Regards
Ed Willink
|
|
|
Re: [CDO] OCL query fails with an SQL statement already in cache [message #1440356 is a reply to message #1439895] |
Wed, 08 October 2014 09:05   |
Eclipse User |
|
|
|
Hi Ed,
Thank you for the explanations. BasicEObjectImpl is a class I know nothing about. It looks indeed like some kind of probe that could be used for logging...
I looked for information but I only found the API and some basic examples on programcreek.com...
Could you please give me details on how to log resource loading and unloading as well as eContainer changes on the Diagram EClass using BasicEObjectImpl.eBasicSetContainer ?
Regards,
Laurent
|
|
|
Re: [CDO] OCL query fails with an SQL statement already in cache [message #1440551 is a reply to message #1440356] |
Wed, 08 October 2014 13:59   |
Eclipse User |
|
|
|
Hi
I'm sorry, but if you do not know how to add println's to Eclipse plugin
sources you are not going to be able to solve your problem.
Regards
Ed Willink
On 08/10/2014 10:05, Laurent Le Moux wrote:
> Hi Ed,
>
> Thank you for the explanations. BasicEObjectImpl is a class I know
> nothing about. It looks indeed like some kind of probe that could be
> used for logging...
>
> I looked for information but I only found the API and some basic
> examples on programcreek.com...
>
> Could you please give me details on how to log resource loading and
> unloading as well as eContainer changes on the Diagram EClass using
> BasicEObjectImpl.eBasicSetContainer ?
>
> Regards,
>
> Laurent
|
|
|
Re: [CDO] OCL query fails with an SQL statement already in cache [message #1444776 is a reply to message #1440551] |
Tue, 14 October 2014 14:37   |
Eclipse User |
|
|
|
Hi again,
Println is widely documented. Whereas I found only the API and 3 basic examples on how to use BasicEObjectImpl :
http://download.eclipse.org/modeling/emf/emf/javadoc/2.5.0/org/eclipse/emf/ecore/impl/BasicEObjectImpl.html
http://www.programcreek.com/java-api-examples/index.php?api=org.eclipse.emf.ecore.impl.BasicEObjectImpl
From these examples and the protected constructor, my first guess was that objects like a CDOResource could be cast as BasicEObjectImpl.
But, eBasicSetContainer() seems to be based on a notification mechanism (thus something more elaborated than a println...).
By the way, the source code indicates that eBasicSetContainer(InternalEObject newContainer, int newContainerFeatureID) throws an UnsupportedOperationException...
https://eclipse.googlesource.com/emf/org.eclipse.emf/+/a1ba85bc37a6dfa3cc9d9ea2e06af978a3acc929/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/impl/BasicEObjectImpl.java
That's the reason why, I am (kindly) asking for a little bit more information than just a method name...
For now, as I'm not able to use BasicEObjectImpl, I tried to get more details about my problem.
The query fails on a cold server but is normally executed once a Graphiti diagram has been open in my application editor (i.e. has been loaded from CDO).
I found another topic with a similar problem. But it remained unanswered :
http://www.eclipse.org/forums/index.php/t/627850/
Basically, the idea seems to be that packages useful for OCL are not available in the CDO package registry.
Hereafter is a log of the package registry for a cold server :
Key : http://user/1.0, Package : user.impl.UserPackageImpl@244bb9 (name: user) (nsURI: http://user/1.0, nsPrefix: user)
Key : http://eclipse.org/graphiti/mm, Package : CDOPackageInfo[packageURI=http://eclipse.org/graphiti/mm, parentURI=null]
Key : http://eclipse.org/graphiti/mm/algorithms/styles, Package : CDOPackageInfo[packageURI=http://eclipse.org/graphiti/mm/algorithms/styles, parentURI=http://eclipse.org/graphiti/mm/algorithms]
Key : http://lemoux.fr/modeling/framework/commons/metadata/commit, Package : CDOPackageInfo[packageURI=http://lemoux.fr/modeling/framework/commons/metadata/commit, parentURI=null]
Key : http://service/2.0, Package : servicev2.impl.Servicev2PackageImpl@1ca6954 (name: servicev2) (nsURI: http://service/2.0, nsPrefix: servicev2)
Key : http://www.eclipse.org/emf/CDO/security/4.1.0, Package : org.eclipse.emf.cdo.security.impl.SecurityPackageImpl@127fa03 (name: security) (nsURI: http://www.eclipse.org/emf/CDO/security/4.1.0, nsPrefix: security)
Key : http://repositorystructure/2.0, Package : repositorystructurev2.impl.Repositorystructurev2PackageImpl@62b39f (name: repositorystructurev2) (nsURI: http://repositorystructure/2.0, nsPrefix: repositorystructurev2)
Key : http://eclipse.org/graphiti/mm/algorithms, Package : CDOPackageInfo[packageURI=http://eclipse.org/graphiti/mm/algorithms, parentURI=http://eclipse.org/graphiti/mm]
Key : http://www.eclipse.org/emf/CDO/Eresource/4.0.0, Package : org.eclipse.emf.cdo.eresource.impl.EresourcePackageImpl@145d424 (name: eresource) (nsURI: http://www.eclipse.org/emf/CDO/Eresource/4.0.0, nsPrefix: eresource)
Key : http://lemoux.fr/modeling/framework/commons/metadata/configuration, Package : metadata.configuration.impl.ConfigurationPackageImpl@b72ce1 (name: configuration) (nsURI: http://lemoux.fr/modeling/framework/commons/metadata/configuration, nsPrefix: co)
Key : http://www.eclipse.org/emf/2002/Ecore, Package : CDOPackageInfo[packageURI=http://www.eclipse.org/emf/2002/Ecore, parentURI=null]
Key : http://www.eclipse.org/emf/CDO/expressions/4.3.0, Package : CDOPackageInfo[packageURI=http://www.eclipse.org/emf/CDO/expressions/4.3.0, parentURI=null]
Key : http://application/2.0, Package : applicationv2.impl.Applicationv2PackageImpl@7e9bed (name: applicationv2) (nsURI: http://application/2.0, nsPrefix: applicationv2)
Key : http://www.eclipse.org/emf/CDO/Etypes/4.0.0, Package : CDOPackageInfo[packageURI=http://www.eclipse.org/emf/CDO/Etypes/4.0.0, parentURI=null]
Key : http://eclipse.org/graphiti/mm/pictograms, Package : CDOPackageInfo[packageURI=http://eclipse.org/graphiti/mm/pictograms, parentURI=http://eclipse.org/graphiti/mm]
And for one from which a diagram has been loaded and my OCL query succefully executed :
Key : http://user/1.0, Package : user.impl.UserPackageImpl@244bb9 (name: user) (nsURI: http://user/1.0, nsPrefix: user)
Key : http://eclipse.org/graphiti/mm, Package : CDOPackageInfo[packageURI=http://eclipse.org/graphiti/mm, parentURI=null]
Key : http://eclipse.org/graphiti/mm/algorithms/styles, Package : org.eclipse.graphiti.mm.algorithms.styles.impl.StylesPackageImpl@1737e47 (name: styles) (nsURI: http://eclipse.org/graphiti/mm/algorithms/styles, nsPrefix: st)
Key : http://lemoux.fr/modeling/framework/commons/metadata/commit, Package : metadata.commit.impl.CommitPackageImpl@1a4071a (name: commit) (nsURI: http://lemoux.fr/modeling/framework/commons/metadata/commit, nsPrefix: cm)
Key : http://service/2.0, Package : servicev2.impl.Servicev2PackageImpl@1ca6954 (name: servicev2) (nsURI: http://service/2.0, nsPrefix: servicev2)
Key : http://www.eclipse.org/emf/CDO/security/4.1.0, Package : org.eclipse.emf.cdo.security.impl.SecurityPackageImpl@127fa03 (name: security) (nsURI: http://www.eclipse.org/emf/CDO/security/4.1.0, nsPrefix: security)
Key : http://repositorystructure/2.0, Package : repositorystructurev2.impl.Repositorystructurev2PackageImpl@62b39f (name: repositorystructurev2) (nsURI: http://repositorystructure/2.0, nsPrefix: repositorystructurev2)
Key : http://eclipse.org/graphiti/mm/algorithms, Package : org.eclipse.graphiti.mm.algorithms.impl.AlgorithmsPackageImpl@8d116e (name: algorithms) (nsURI: http://eclipse.org/graphiti/mm/algorithms, nsPrefix: al)
Key : http://www.eclipse.org/emf/CDO/Eresource/4.0.0, Package : org.eclipse.emf.cdo.eresource.impl.EresourcePackageImpl@145d424 (name: eresource) (nsURI: http://www.eclipse.org/emf/CDO/Eresource/4.0.0, nsPrefix: eresource)
Key : http://lemoux.fr/modeling/framework/commons/metadata/configuration, Package : metadata.configuration.impl.ConfigurationPackageImpl@b72ce1 (name: configuration) (nsURI: http://lemoux.fr/modeling/framework/commons/metadata/configuration, nsPrefix: co)
Key : http://www.eclipse.org/emf/2002/Ecore, Package : CDOPackageInfo[packageURI=http://www.eclipse.org/emf/2002/Ecore, parentURI=null]
Key : http://www.eclipse.org/emf/CDO/expressions/4.3.0, Package : CDOPackageInfo[packageURI=http://www.eclipse.org/emf/CDO/expressions/4.3.0, parentURI=null]
Key : http://application/2.0, Package : applicationv2.impl.Applicationv2PackageImpl@7e9bed (name: applicationv2) (nsURI: http://application/2.0, nsPrefix: applicationv2)
Key : http://www.eclipse.org/emf/CDO/Etypes/4.0.0, Package : CDOPackageInfo[packageURI=http://www.eclipse.org/emf/CDO/Etypes/4.0.0, parentURI=null]
Key : http://eclipse.org/graphiti/mm/pictograms, Package : org.eclipse.graphiti.mm.pictograms.impl.PictogramsPackageImpl@1d62a85 (name: pictograms) (nsURI: http://eclipse.org/graphiti/mm/pictograms, nsPrefix: pi)
I tried to "force" package registration as follow, but it makes no change :
CDOPackageRegistry packageRegistry = transaction.getSession().getPackageRegistry();
Iterator<Entry<String, Object>> it = packageRegistry.entrySet().iterator();
while (it.hasNext()) {
Entry<String, Object> item = it.next();
if ((item.getValue() instanceof MmPackage) || (item.getValue() instanceof AlgorithmsPackage)
|| (item.getValue() instanceof PictogramsPackage))
it.remove();
}
packageRegistry.putEPackage(MmPackage.eINSTANCE);
packageRegistry.putEPackage(AlgorithmsPackage.eINSTANCE);
packageRegistry.putEPackage(PictogramsPackage.eINSTANCE);
// 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);
The OCL query is still failing on a cold server.. 
Hope someone can help...
Regards,
Laurent
|
|
|
Re: [CDO] OCL query fails with an SQL statement already in cache [message #1444786 is a reply to message #1444776] |
Tue, 14 October 2014 14:54   |
Eclipse User |
|
|
|
One more information if it helps...
Loading a Graphiti diagram from CDO into my editor is done the following way :
From an element in the repository selected by the user in a navigator tree, I get its containing CDO resource. From there, I look for the diagram in the resource and I open the editor providing an editor input with the diagram URI.
Whereas, the OCL query is executed on the selected element. And I try to get the diagram(s) back without navigating through my repository elements and their resource.
So, there's no explicit resource loading in the second case...
|
|
|
Re: [CDO] OCL query fails with an SQL statement already in cache [message #1445353 is a reply to message #1444786] |
Wed, 15 October 2014 10:19   |
Eclipse User |
|
|
|
Hi again,
I finally found a solution based on other CDO / OCL users answers in the topics mentioned above.
I imported the 'org.eclipse.ecore.ocl' plugin as source project to modify EcoreEnvironment.findPackage as follow and deployed again my CDO server with this modified plugin :
...
for (Object next : registry.values()) {
EPackage ePackage = null;
if (next instanceof CDOPackageInfo)
ePackage = ((CDOPackageInfo) next).getEPackage();
if (next instanceof EPackage)
ePackage = (EPackage) next;
if (ePackage != null) {
// only consider root-level packages when searching by name
if ((ePackage.getESuperPackage() == null)
&& EcoreForeignMethods.isNamed(name, ePackage)) {
EPackage tentativeResult = findNestedPackage(
packageNames.subList(1, packageNames.size()),
ePackage);
if (tentativeResult != null) {
return tentativeResult;
}
}
}
}
...
I also had to disable performance tuning on my CDO client side as explained in the bug 339948 :
https://bugs.eclipse.org/bugs/show_bug.cgi?id=339948
My OCL queries are now working fine on a cold CDO server.
But I introduced a dependency on 'org.eclipse.emf.cdo.common' in 'org.eclipse.ecore.ocl'.
I push this information to the opened bug 435807 :
https://bugs.eclipse.org/bugs/show_bug.cgi?id=435807
Kind regards,
Laurent
|
|
|
Re: [CDO] OCL query fails with an SQL statement already in cache [message #1446102 is a reply to message #1445353] |
Thu, 16 October 2014 11:07  |
Eclipse User |
|
|
|
Hi
Well solved.
Please use Bugzilla as the primary communication channel for bugs.
Discussion continues on
https://bugs.eclipse.org/bugs/show_bug.cgi?id=435807.
Regards
Ed Willink
On 15/10/2014 11:19, Laurent Le Moux wrote:
> Hi again,
>
> I finally found a solution based on other CDO / OCL users answers in the
> topics mentioned above.
>
> I imported the 'org.eclipse.ecore.ocl' plugin as source project to
> modify EcoreEnvironment.findPackage as follow and deployed again my CDO
> server with this modified plugin :
>
>
> ..
> for (Object next : registry.values()) {
> EPackage ePackage = null;
> if (next instanceof CDOPackageInfo)
> ePackage = ((CDOPackageInfo) next).getEPackage();
> if (next instanceof EPackage)
> ePackage = (EPackage) next;
>
> if (ePackage != null) {
> // only consider root-level packages when searching by name
> if ((ePackage.getESuperPackage() == null)
> && EcoreForeignMethods.isNamed(name, ePackage)) {
>
> EPackage tentativeResult = findNestedPackage(
> packageNames.subList(1, packageNames.size()),
> ePackage);
>
> if (tentativeResult != null) {
> return tentativeResult;
> }
> }
> }
> }
> ..
>
>
> I also had to disable performance tuning on my CDO client side as
> explained in the bug 339948 :
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=339948
>
> My OCL queries are now working fine on a cold CDO server.
> But I introduced a dependency on 'org.eclipse.emf.cdo.common' in
> 'org.eclipse.ecore.ocl'.
>
> I push this information to the opened bug 435807 :
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=435807
>
> Kind regards,
>
> Laurent
|
|
|
Goto Forum:
Current Time: Thu Feb 13 10:28:11 GMT 2025
Powered by FUDForum. Page generated in 0.05319 seconds
|