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 15: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 15: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 16: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 02: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 #1438188 is a reply to message #1436877] |
Sun, 05 October 2014 13: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 #1444776 is a reply to message #1440551] |
Tue, 14 October 2014 10: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 #1446102 is a reply to message #1445353] |
Thu, 16 October 2014 07: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: Sat Mar 15 23:12:25 EDT 2025
Powered by FUDForum. Page generated in 0.05792 seconds
|