Eclipse Community Forums - RDF feed
https://www.eclipse.org/forums/
Eclipse Community Forums[CDO] No suitable mapping found from EMF type CUSTOM to DB type DBType
https://www.eclipse.org/forums/index.php/mv/msg/136804/431731/#msg_431731
my RCP app.
When starting my app I get the below exception.
So it seems the mapping doen't like some type in my EMF model (it worked perfectly with 2.0).
But the error message is so unhandy that no one could tell what exactly the cause is. At least the
feature structure should be also named.
Also I am not sure why the EMF type "CUSTOM" is used. I am not using any special in my EMF models.
Regards,
Kai]]>Kai Schlamp2009-07-23T12:08:53-00:00Re: [CDO] No suitable mapping found from EMF type CUSTOM to DB type DBType
https://www.eclipse.org/forums/index.php/mv/msg/136804/431732/#msg_431732
Rollback in DBStore: java.lang.IllegalArgumentException: No suitable mapping found from EMF type
CUSTOM to DB type DBType
at
org.eclipse.emf.cdo.server.internal.db.mapping.TypeMappingFa ctory.createTypeMapping(TypeMappingFactory.java:255)
at
org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.createValueMapping(AbstractMappingStrategy.java:3 88)
at
org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ab stractHorizontalClassMapping.createValueMappings(AbstractHor izontalClassMapping.java:119)
at
org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ab stractHorizontalClassMapping.initFeatures(AbstractHorizontal ClassMapping.java:107)
at
org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ab stractHorizontalClassMapping. <init>(AbstractHorizontalClassMapping.java:76)
at
org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ho rizontalNonAuditClassMapping. <init>(HorizontalNonAuditClassMapping.java:90)
at
org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ho rizontalNonAuditMappingStrategy.doCreateClassMapping(Horizon talNonAuditMappingStrategy.java:29)
at
org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.createClassMapping(AbstractMappingStrategy.java:3 55)
at
org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.mapClasses(AbstractMappingStrategy.java:325)
at
org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.mapPackageInfos(AbstractMappingStrategy.java:314)
at
org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.mapPackageUnits(AbstractMappingStrategy.java:336)
at
org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.createMapping(AbstractMappingStrategy.java:297)
at org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.write PackageUnits(DBStoreAccessor.java:501)
at org.eclipse.emf.cdo.spi.server.StoreAccessor.write(StoreAcce ssor.java:132)
at org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.acces s$4(DBStoreAccessor.java:1)
at org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor$1.run Loop(DBStoreAccessor.java:80)
at org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor$1.run Loop(DBStoreAccessor.java:1)
at org.eclipse.net4j.util.om.monitor.ProgressDistributor.run(Pr ogressDistributor.java:96)
at org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.write (DBStoreAccessor.java:299)
at
org.eclipse.emf.cdo.internal.server.TransactionCommitContext Impl.write(TransactionCommitContextImpl.java:273)
at
org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication$1.runLoop(CommitTransactionIndication.jav a:72)
at
org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication$1.runLoop(CommitTransactionIndication.jav a:1)
at org.eclipse.net4j.util.om.monitor.ProgressDistributor.run(Pr ogressDistributor.java:96)
at
org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication.indicatingCommit(CommitTransactionIndicat ion.java:280)
at
org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication.indicating(CommitTransactionIndication.ja va:173)
at
org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication.indicating(CommitTransactionIndication.ja va:139)
at org.eclipse.net4j.signal.IndicationWithMonitoring.indicating (IndicationWithMonitoring.java:84)
at org.eclipse.net4j.signal.IndicationWithResponse.doExtendedIn put(IndicationWithResponse.java:90)
at org.eclipse.net4j.signal.Signal.doInput(Signal.java:312)
at org.eclipse.net4j.signal.IndicationWithResponse.execute(Indi cationWithResponse.java:63)
at org.eclipse.net4j.signal.IndicationWithMonitoring.execute(In dicationWithMonitoring.java:63)
at org.eclipse.net4j.signal.Signal.runSync(Signal.java:239)
at org.eclipse.net4j.signal.Signal.run(Signal.java:147)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Threa dPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo lExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
at org.pubcurator.core.managers.ServerManager.connectToServer(S erverManager.java:228)
at org.pubcurator.core.managers.ServerManager.connectToLocalSer ver(ServerManager.java:186)
at org.pubcurator.core.ApplicationWorkbenchAdvisor$1$1.run(Appl icationWorkbenchAdvisor.java:87)
at org.eclipse.jface.operation.ModalContext$ModalContextThread. run(ModalContext.java:121)
Kai Schlamp wrote:
> As I mentioned in my previous message I switched from CDO 2.0 to the
> current CVS Head as target for my RCP app.
> When starting my app I get the below exception.
> So it seems the mapping doen't like some type in my EMF model (it worked
> perfectly with 2.0).
> But the error message is so unhandy that no one could tell what exactly
> the cause is. At least the feature structure should be also named.
> Also I am not sure why the EMF type "CUSTOM" is used. I am not using any
> special in my EMF models.
>
> Regards,
> Kai]]>Kai Schlamp2009-07-23T12:09:39-00:00Re: [CDO] No suitable mapping found from EMF type CUSTOM to DB type DBType
https://www.eclipse.org/forums/index.php/mv/msg/136804/431734/#msg_431734
My model has indeed a custom field (EJavaObject), but I never commit any of those objects with this
feature structure into the database.
CDO 2.0 could live with that and was never interested in that never persisted object. In contrast
CDO CVS Head now is interested in those objects when setting up the database and throws the below
exception.
In my opinion we should make CDO Head behave as CDO 2.0. Only do mappings when needed.
Regards,
Kai
Kai Schlamp wrote:
> Forgot the trace:
>
> Rollback in DBStore: java.lang.IllegalArgumentException: No suitable
> mapping found from EMF type CUSTOM to DB type DBType
> at
> org.eclipse.emf.cdo.server.internal.db.mapping.TypeMappingFa ctory.createTypeMapping(TypeMappingFactory.java:255)
>
> at
> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.createValueMapping(AbstractMappingStrategy.java:3 88)
>
> at
> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ab stractHorizontalClassMapping.createValueMappings(AbstractHor izontalClassMapping.java:119)
>
> at
> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ab stractHorizontalClassMapping.initFeatures(AbstractHorizontal ClassMapping.java:107)
>
> at
> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ab stractHorizontalClassMapping. <init>(AbstractHorizontalClassMapping.java:76)
>
> at
> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ho rizontalNonAuditClassMapping. <init>(HorizontalNonAuditClassMapping.java:90)
>
> at
> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ho rizontalNonAuditMappingStrategy.doCreateClassMapping(Horizon talNonAuditMappingStrategy.java:29)
>
> at
> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.createClassMapping(AbstractMappingStrategy.java:3 55)
>
> at
> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.mapClasses(AbstractMappingStrategy.java:325)
>
> at
> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.mapPackageInfos(AbstractMappingStrategy.java:314)
>
> at
> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.mapPackageUnits(AbstractMappingStrategy.java:336)
>
> at
> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.createMapping(AbstractMappingStrategy.java:297)
>
> at
> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.write PackageUnits(DBStoreAccessor.java:501)
>
> at
> org.eclipse.emf.cdo.spi.server.StoreAccessor.write(StoreAcce ssor.java:132)
> at
> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.acces s$4(DBStoreAccessor.java:1)
>
> at
> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor$1.run Loop(DBStoreAccessor.java:80)
>
> at
> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor$1.run Loop(DBStoreAccessor.java:1)
>
> at
> org.eclipse.net4j.util.om.monitor.ProgressDistributor.run(Pr ogressDistributor.java:96)
>
> at
> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.write (DBStoreAccessor.java:299)
>
> at
> org.eclipse.emf.cdo.internal.server.TransactionCommitContext Impl.write(TransactionCommitContextImpl.java:273)
>
> at
> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication$1.runLoop(CommitTransactionIndication.jav a:72)
>
> at
> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication$1.runLoop(CommitTransactionIndication.jav a:1)
>
> at
> org.eclipse.net4j.util.om.monitor.ProgressDistributor.run(Pr ogressDistributor.java:96)
>
> at
> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication.indicatingCommit(CommitTransactionIndicat ion.java:280)
>
> at
> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication.indicating(CommitTransactionIndication.ja va:173)
>
> at
> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication.indicating(CommitTransactionIndication.ja va:139)
>
> at
> org.eclipse.net4j.signal.IndicationWithMonitoring.indicating (IndicationWithMonitoring.java:84)
>
> at
> org.eclipse.net4j.signal.IndicationWithResponse.doExtendedIn put(IndicationWithResponse.java:90)
>
> at org.eclipse.net4j.signal.Signal.doInput(Signal.java:312)
> at
> org.eclipse.net4j.signal.IndicationWithResponse.execute(Indi cationWithResponse.java:63)
>
> at
> org.eclipse.net4j.signal.IndicationWithMonitoring.execute(In dicationWithMonitoring.java:63)
>
> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:239)
> at org.eclipse.net4j.signal.Signal.run(Signal.java:147)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Threa dPoolExecutor.java:886)
>
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo lExecutor.java:908)
>
> at java.lang.Thread.run(Thread.java:619)
>
> at
> org.pubcurator.core.managers.ServerManager.connectToServer(S erverManager.java:228)
>
> at
> org.pubcurator.core.managers.ServerManager.connectToLocalSer ver(ServerManager.java:186)
>
> at
> org.pubcurator.core.ApplicationWorkbenchAdvisor$1$1.run(Appl icationWorkbenchAdvisor.java:87)
>
> at
> org.eclipse.jface.operation.ModalContext$ModalContextThread. run(ModalContext.java:121)
>
>
>
> Kai Schlamp wrote:
>> As I mentioned in my previous message I switched from CDO 2.0 to the
>> current CVS Head as target for my RCP app.
>> When starting my app I get the below exception.
>> So it seems the mapping doen't like some type in my EMF model (it
>> worked perfectly with 2.0).
>> But the error message is so unhandy that no one could tell what
>> exactly the cause is. At least the feature structure should be also
>> named.
>> Also I am not sure why the EMF type "CUSTOM" is used. I am not using
>> any special in my EMF models.
>>
>> Regards,
>> Kai]]>Kai Schlamp2009-07-23T12:30:22-00:00Re: [CDO] No suitable mapping found from EMF type CUSTOM to DB type DBType
https://www.eclipse.org/forums/index.php/mv/msg/136804/431735/#msg_431735
Tom
Kai Schlamp schrieb:
> Ok, here lies the problem.
> My model has indeed a custom field (EJavaObject), but I never commit any
> of those objects with this feature structure into the database.
> CDO 2.0 could live with that and was never interested in that never
> persisted object. In contrast CDO CVS Head now is interested in those
> objects when setting up the database and throws the below exception.
> In my opinion we should make CDO Head behave as CDO 2.0. Only do
> mappings when needed.
>
> Regards,
> Kai
>
>
> Kai Schlamp wrote:
>> Forgot the trace:
>>
>> Rollback in DBStore: java.lang.IllegalArgumentException: No suitable
>> mapping found from EMF type CUSTOM to DB type DBType
>> at
>> org.eclipse.emf.cdo.server.internal.db.mapping.TypeMappingFa ctory.createTypeMapping(TypeMappingFactory.java:255)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.createValueMapping(AbstractMappingStrategy.java:3 88)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ab stractHorizontalClassMapping.createValueMappings(AbstractHor izontalClassMapping.java:119)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ab stractHorizontalClassMapping.initFeatures(AbstractHorizontal ClassMapping.java:107)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ab stractHorizontalClassMapping. <init>(AbstractHorizontalClassMapping.java:76)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ho rizontalNonAuditClassMapping. <init>(HorizontalNonAuditClassMapping.java:90)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ho rizontalNonAuditMappingStrategy.doCreateClassMapping(Horizon talNonAuditMappingStrategy.java:29)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.createClassMapping(AbstractMappingStrategy.java:3 55)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.mapClasses(AbstractMappingStrategy.java:325)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.mapPackageInfos(AbstractMappingStrategy.java:314)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.mapPackageUnits(AbstractMappingStrategy.java:336)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.createMapping(AbstractMappingStrategy.java:297)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.write PackageUnits(DBStoreAccessor.java:501)
>>
>> at
>> org.eclipse.emf.cdo.spi.server.StoreAccessor.write(StoreAcce ssor.java:132)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.acces s$4(DBStoreAccessor.java:1)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor$1.run Loop(DBStoreAccessor.java:80)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor$1.run Loop(DBStoreAccessor.java:1)
>>
>> at
>> org.eclipse.net4j.util.om.monitor.ProgressDistributor.run(Pr ogressDistributor.java:96)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.write (DBStoreAccessor.java:299)
>>
>> at
>> org.eclipse.emf.cdo.internal.server.TransactionCommitContext Impl.write(TransactionCommitContextImpl.java:273)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication$1.runLoop(CommitTransactionIndication.jav a:72)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication$1.runLoop(CommitTransactionIndication.jav a:1)
>>
>> at
>> org.eclipse.net4j.util.om.monitor.ProgressDistributor.run(Pr ogressDistributor.java:96)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication.indicatingCommit(CommitTransactionIndicat ion.java:280)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication.indicating(CommitTransactionIndication.ja va:173)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication.indicating(CommitTransactionIndication.ja va:139)
>>
>> at
>> org.eclipse.net4j.signal.IndicationWithMonitoring.indicating (IndicationWithMonitoring.java:84)
>>
>> at
>> org.eclipse.net4j.signal.IndicationWithResponse.doExtendedIn put(IndicationWithResponse.java:90)
>>
>> at org.eclipse.net4j.signal.Signal.doInput(Signal.java:312)
>> at
>> org.eclipse.net4j.signal.IndicationWithResponse.execute(Indi cationWithResponse.java:63)
>>
>> at
>> org.eclipse.net4j.signal.IndicationWithMonitoring.execute(In dicationWithMonitoring.java:63)
>>
>> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:239)
>> at org.eclipse.net4j.signal.Signal.run(Signal.java:147)
>> at
>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Threa dPoolExecutor.java:886)
>>
>> at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo lExecutor.java:908)
>>
>> at java.lang.Thread.run(Thread.java:619)
>>
>> at
>> org.pubcurator.core.managers.ServerManager.connectToServer(S erverManager.java:228)
>>
>> at
>> org.pubcurator.core.managers.ServerManager.connectToLocalSer ver(ServerManager.java:186)
>>
>> at
>> org.pubcurator.core.ApplicationWorkbenchAdvisor$1$1.run(Appl icationWorkbenchAdvisor.java:87)
>>
>> at
>> org.eclipse.jface.operation.ModalContext$ModalContextThread. run(ModalContext.java:121)
>>
>>
>>
>> Kai Schlamp wrote:
>>> As I mentioned in my previous message I switched from CDO 2.0 to the
>>> current CVS Head as target for my RCP app.
>>> When starting my app I get the below exception.
>>> So it seems the mapping doen't like some type in my EMF model (it
>>> worked perfectly with 2.0).
>>> But the error message is so unhandy that no one could tell what
>>> exactly the cause is. At least the feature structure should be also
>>> named.
>>> Also I am not sure why the EMF type "CUSTOM" is used. I am not using
>>> any special in my EMF models.
>>>
>>> Regards,
>>> Kai]]>Thomas Schindl2009-07-23T12:35:45-00:00Re: [CDO] No suitable mapping found from EMF type CUSTOM to DB type DBType
https://www.eclipse.org/forums/index.php/mv/msg/136804/431736/#msg_431736
> the cause is. At least the feature structure should be also named.
Here is a little patch for a more detailed error message. Please don't ask me to add a bugzilla for
that little line ;-)
### Eclipse Workspace Patch 1.0
#P org.eclipse.emf.cdo.server.db
Index: src/org/eclipse/emf/cdo/server/internal/db/mapping/TypeMappi ngFactory.java
============================================================ =======
RCS file:
/cvsroot/modeling/org.eclipse.emf/org.eclipse.emf.cdo/plugin s/org.eclipse.emf.cdo.server.db/src/org/eclipse/emf/cdo/serv er/internal/db/mapping/TypeMappingFactory.java,v
retrieving revision 1.2
diff -u -r1.2 TypeMappingFactory.java
--- src/org/eclipse/emf/cdo/server/internal/db/mapping/TypeMappi ngFactory.java 17 Jul 2009
09:05:02 -0000 1.2
+++ src/org/eclipse/emf/cdo/server/internal/db/mapping/TypeMappi ngFactory.java 23 Jul 2009 12:32:50
-0000
@@ -253,7 +253,8 @@
if (concreteFactory == null)
{
throw new IllegalArgumentException("No suitable mapping found from EMF type " +
cdoType.getName()
- + " to DB type " + dbType.getClass().getSimpleName());
+ + " to DB type " + dbType.getClass().getSimpleName() + " for feature " +
feature.getName() + " of "
+ + feature.getEContainingClass().getName());
}
return concreteFactory.doCreateTypeMapping(mappingStrategy, feature, dbType);]]>Kai Schlamp2009-07-23T12:36:03-00:00Re: [CDO] No suitable mapping found from EMF type CUSTOM to DB type DBType
https://www.eclipse.org/forums/index.php/mv/msg/136804/431737/#msg_431737
more a conceptual question of how CDO works. Why does CDO bother with type mappings when nothing is
intended to be committed. But I am still not sure for myself ... is it intended or even a feature?!
As I said, it behave differently when using CDO 2.0 that's why it attracted my attention.
Regards,
Kai
Tom Schindl wrote:
> Shouldn't the field be transient?
>
> Tom
>
> Kai Schlamp schrieb:
>> Ok, here lies the problem.
>> My model has indeed a custom field (EJavaObject), but I never commit any
>> of those objects with this feature structure into the database.
>> CDO 2.0 could live with that and was never interested in that never
>> persisted object. In contrast CDO CVS Head now is interested in those
>> objects when setting up the database and throws the below exception.
>> In my opinion we should make CDO Head behave as CDO 2.0. Only do
>> mappings when needed.
>>
>> Regards,
>> Kai
>>
>>
>> Kai Schlamp wrote:
>>> Forgot the trace:
>>>
>>> Rollback in DBStore: java.lang.IllegalArgumentException: No suitable
>>> mapping found from EMF type CUSTOM to DB type DBType
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.mapping.TypeMappingFa ctory.createTypeMapping(TypeMappingFactory.java:255)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.createValueMapping(AbstractMappingStrategy.java:3 88)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ab stractHorizontalClassMapping.createValueMappings(AbstractHor izontalClassMapping.java:119)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ab stractHorizontalClassMapping.initFeatures(AbstractHorizontal ClassMapping.java:107)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ab stractHorizontalClassMapping. <init>(AbstractHorizontalClassMapping.java:76)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ho rizontalNonAuditClassMapping. <init>(HorizontalNonAuditClassMapping.java:90)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ho rizontalNonAuditMappingStrategy.doCreateClassMapping(Horizon talNonAuditMappingStrategy.java:29)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.createClassMapping(AbstractMappingStrategy.java:3 55)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.mapClasses(AbstractMappingStrategy.java:325)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.mapPackageInfos(AbstractMappingStrategy.java:314)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.mapPackageUnits(AbstractMappingStrategy.java:336)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.createMapping(AbstractMappingStrategy.java:297)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.write PackageUnits(DBStoreAccessor.java:501)
>>>
>>> at
>>> org.eclipse.emf.cdo.spi.server.StoreAccessor.write(StoreAcce ssor.java:132)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.acces s$4(DBStoreAccessor.java:1)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor$1.run Loop(DBStoreAccessor.java:80)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor$1.run Loop(DBStoreAccessor.java:1)
>>>
>>> at
>>> org.eclipse.net4j.util.om.monitor.ProgressDistributor.run(Pr ogressDistributor.java:96)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.write (DBStoreAccessor.java:299)
>>>
>>> at
>>> org.eclipse.emf.cdo.internal.server.TransactionCommitContext Impl.write(TransactionCommitContextImpl.java:273)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication$1.runLoop(CommitTransactionIndication.jav a:72)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication$1.runLoop(CommitTransactionIndication.jav a:1)
>>>
>>> at
>>> org.eclipse.net4j.util.om.monitor.ProgressDistributor.run(Pr ogressDistributor.java:96)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication.indicatingCommit(CommitTransactionIndicat ion.java:280)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication.indicating(CommitTransactionIndication.ja va:173)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication.indicating(CommitTransactionIndication.ja va:139)
>>>
>>> at
>>> org.eclipse.net4j.signal.IndicationWithMonitoring.indicating (IndicationWithMonitoring.java:84)
>>>
>>> at
>>> org.eclipse.net4j.signal.IndicationWithResponse.doExtendedIn put(IndicationWithResponse.java:90)
>>>
>>> at org.eclipse.net4j.signal.Signal.doInput(Signal.java:312)
>>> at
>>> org.eclipse.net4j.signal.IndicationWithResponse.execute(Indi cationWithResponse.java:63)
>>>
>>> at
>>> org.eclipse.net4j.signal.IndicationWithMonitoring.execute(In dicationWithMonitoring.java:63)
>>>
>>> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:239)
>>> at org.eclipse.net4j.signal.Signal.run(Signal.java:147)
>>> at
>>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Threa dPoolExecutor.java:886)
>>>
>>> at
>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo lExecutor.java:908)
>>>
>>> at java.lang.Thread.run(Thread.java:619)
>>>
>>> at
>>> org.pubcurator.core.managers.ServerManager.connectToServer(S erverManager.java:228)
>>>
>>> at
>>> org.pubcurator.core.managers.ServerManager.connectToLocalSer ver(ServerManager.java:186)
>>>
>>> at
>>> org.pubcurator.core.ApplicationWorkbenchAdvisor$1$1.run(Appl icationWorkbenchAdvisor.java:87)
>>>
>>> at
>>> org.eclipse.jface.operation.ModalContext$ModalContextThread. run(ModalContext.java:121)
>>>
>>>
>>>
>>> Kai Schlamp wrote:
>>>> As I mentioned in my previous message I switched from CDO 2.0 to the
>>>> current CVS Head as target for my RCP app.
>>>> When starting my app I get the below exception.
>>>> So it seems the mapping doen't like some type in my EMF model (it
>>>> worked perfectly with 2.0).
>>>> But the error message is so unhandy that no one could tell what
>>>> exactly the cause is. At least the feature structure should be also
>>>> named.
>>>> Also I am not sure why the EMF type "CUSTOM" is used. I am not using
>>>> any special in my EMF models.
>>>>
>>>> Regards,
>>>> Kai]]>Kai Schlamp2009-07-23T12:43:29-00:00Re: [CDO] No suitable mapping found from EMF type CUSTOM to DB type DBType
https://www.eclipse.org/forums/index.php/mv/msg/136804/431738/#msg_431738
because all projects need to maintain an IP-Log.
Tom
Kai Schlamp schrieb:
>> But the error message is so unhandy that no one could tell what
>> exactly the cause is. At least the feature structure should be also
>> named.
>
> Here is a little patch for a more detailed error message. Please don't
> ask me to add a bugzilla for that little line ;-)
>
> ### Eclipse Workspace Patch 1.0
> #P org.eclipse.emf.cdo.server.db
> Index:
> src/org/eclipse/emf/cdo/server/internal/db/mapping/TypeMappi ngFactory.java
> ============================================================ =======
> RCS file:
> /cvsroot/modeling/org.eclipse.emf/org.eclipse.emf.cdo/plugin s/org.eclipse.emf.cdo.server.db/src/org/eclipse/emf/cdo/serv er/internal/db/mapping/TypeMappingFactory.java,v
>
> retrieving revision 1.2
> diff -u -r1.2 TypeMappingFactory.java
> ---
> src/org/eclipse/emf/cdo/server/internal/db/mapping/TypeMappi ngFactory.java
> 17 Jul 2009 09:05:02 -0000 1.2
> +++
> src/org/eclipse/emf/cdo/server/internal/db/mapping/TypeMappi ngFactory.java
> 23 Jul 2009 12:32:50 -0000
> @@ -253,7 +253,8 @@
> if (concreteFactory == null)
> {
> throw new IllegalArgumentException("No suitable mapping found
> from EMF type " + cdoType.getName()
> - + " to DB type " + dbType.getClass().getSimpleName());
> + + " to DB type " + dbType.getClass().getSimpleName() + " for
> feature " + feature.getName() + " of "
> + + feature.getEContainingClass().getName());
> }
>
> return concreteFactory.doCreateTypeMapping(mappingStrategy,
> feature, dbType);]]>Thomas Schindl2009-07-23T12:49:16-00:00Re: [CDO] No suitable mapping found from EMF type CUSTOM to DB type DBType
https://www.eclipse.org/forums/index.php/mv/msg/136804/431739/#msg_431739
https://bugs.eclipse.org/bugs/show_bug.cgi?id=284412
Tom Schindl wrote:
> There's no other possibility to bring in code into the Eclipse Repo
> because all projects need to maintain an IP-Log.
>
> Tom
>
> Kai Schlamp schrieb:
>>> But the error message is so unhandy that no one could tell what
>>> exactly the cause is. At least the feature structure should be also
>>> named.
>> Here is a little patch for a more detailed error message. Please don't
>> ask me to add a bugzilla for that little line ;-)
>>
>> ### Eclipse Workspace Patch 1.0
>> #P org.eclipse.emf.cdo.server.db
>> Index:
>> src/org/eclipse/emf/cdo/server/internal/db/mapping/TypeMappi ngFactory.java
>> ============================================================ =======
>> RCS file:
>> /cvsroot/modeling/org.eclipse.emf/org.eclipse.emf.cdo/plugin s/org.eclipse.emf.cdo.server.db/src/org/eclipse/emf/cdo/serv er/internal/db/mapping/TypeMappingFactory.java,v
>>
>> retrieving revision 1.2
>> diff -u -r1.2 TypeMappingFactory.java
>> ---
>> src/org/eclipse/emf/cdo/server/internal/db/mapping/TypeMappi ngFactory.java
>> 17 Jul 2009 09:05:02 -0000 1.2
>> +++
>> src/org/eclipse/emf/cdo/server/internal/db/mapping/TypeMappi ngFactory.java
>> 23 Jul 2009 12:32:50 -0000
>> @@ -253,7 +253,8 @@
>> if (concreteFactory == null)
>> {
>> throw new IllegalArgumentException("No suitable mapping found
>> from EMF type " + cdoType.getName()
>> - + " to DB type " + dbType.getClass().getSimpleName());
>> + + " to DB type " + dbType.getClass().getSimpleName() + " for
>> feature " + feature.getName() + " of "
>> + + feature.getEContainingClass().getName());
>> }
>>
>> return concreteFactory.doCreateTypeMapping(mappingStrategy,
>> feature, dbType);]]>Kai Schlamp2009-07-23T13:07:30-00:00Re: [CDO] No suitable mapping found from EMF type CUSTOM to DB type DBType
https://www.eclipse.org/forums/index.php/mv/msg/136804/431754/#msg_431754
The exception message looks odd. Please file a bugzilla and prefix the
summary with "[DB] ...".
It should be: "No suitable mapping found from CDOType CUSTOM to
DBType.BLABLA" or just "No suitable mapping found from CDOType CUSTOM"...
Kai Schlamp schrieb:
> Forgot the trace:
>
> Rollback in DBStore: java.lang.IllegalArgumentException: No suitable
> mapping found from EMF type CUSTOM to DB type DBType
> at
> org.eclipse.emf.cdo.server.internal.db.mapping.TypeMappingFa ctory.createTypeMapping(TypeMappingFactory.java:255)
>
> at
> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.createValueMapping(AbstractMappingStrategy.java:3 88)
>
> at
> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ab stractHorizontalClassMapping.createValueMappings(AbstractHor izontalClassMapping.java:119)
>
> at
> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ab stractHorizontalClassMapping.initFeatures(AbstractHorizontal ClassMapping.java:107)
>
> at
> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ab stractHorizontalClassMapping. <init>(AbstractHorizontalClassMapping.java:76)
>
> at
> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ho rizontalNonAuditClassMapping. <init>(HorizontalNonAuditClassMapping.java:90)
>
> at
> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ho rizontalNonAuditMappingStrategy.doCreateClassMapping(Horizon talNonAuditMappingStrategy.java:29)
>
> at
> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.createClassMapping(AbstractMappingStrategy.java:3 55)
>
> at
> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.mapClasses(AbstractMappingStrategy.java:325)
>
> at
> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.mapPackageInfos(AbstractMappingStrategy.java:314)
>
> at
> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.mapPackageUnits(AbstractMappingStrategy.java:336)
>
> at
> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.createMapping(AbstractMappingStrategy.java:297)
>
> at
> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.write PackageUnits(DBStoreAccessor.java:501)
>
> at
> org.eclipse.emf.cdo.spi.server.StoreAccessor.write(StoreAcce ssor.java:132)
>
> at
> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.acces s$4(DBStoreAccessor.java:1)
>
> at
> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor$1.run Loop(DBStoreAccessor.java:80)
>
> at
> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor$1.run Loop(DBStoreAccessor.java:1)
>
> at
> org.eclipse.net4j.util.om.monitor.ProgressDistributor.run(Pr ogressDistributor.java:96)
>
> at
> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.write (DBStoreAccessor.java:299)
>
> at
> org.eclipse.emf.cdo.internal.server.TransactionCommitContext Impl.write(TransactionCommitContextImpl.java:273)
>
> at
> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication$1.runLoop(CommitTransactionIndication.jav a:72)
>
> at
> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication$1.runLoop(CommitTransactionIndication.jav a:1)
>
> at
> org.eclipse.net4j.util.om.monitor.ProgressDistributor.run(Pr ogressDistributor.java:96)
>
> at
> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication.indicatingCommit(CommitTransactionIndicat ion.java:280)
>
> at
> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication.indicating(CommitTransactionIndication.ja va:173)
>
> at
> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication.indicating(CommitTransactionIndication.ja va:139)
>
> at
> org.eclipse.net4j.signal.IndicationWithMonitoring.indicating (IndicationWithMonitoring.java:84)
>
> at
> org.eclipse.net4j.signal.IndicationWithResponse.doExtendedIn put(IndicationWithResponse.java:90)
>
> at org.eclipse.net4j.signal.Signal.doInput(Signal.java:312)
> at
> org.eclipse.net4j.signal.IndicationWithResponse.execute(Indi cationWithResponse.java:63)
>
> at
> org.eclipse.net4j.signal.IndicationWithMonitoring.execute(In dicationWithMonitoring.java:63)
>
> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:239)
> at org.eclipse.net4j.signal.Signal.run(Signal.java:147)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Threa dPoolExecutor.java:886)
>
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo lExecutor.java:908)
>
> at java.lang.Thread.run(Thread.java:619)
>
> at
> org.pubcurator.core.managers.ServerManager.connectToServer(S erverManager.java:228)
>
> at
> org.pubcurator.core.managers.ServerManager.connectToLocalSer ver(ServerManager.java:186)
>
> at
> org.pubcurator.core.ApplicationWorkbenchAdvisor$1$1.run(Appl icationWorkbenchAdvisor.java:87)
>
> at
> org.eclipse.jface.operation.ModalContext$ModalContextThread. run(ModalContext.java:121)
>
>
>
> Kai Schlamp wrote:
>> As I mentioned in my previous message I switched from CDO 2.0 to the
>> current CVS Head as target for my RCP app.
>> When starting my app I get the below exception.
>> So it seems the mapping doen't like some type in my EMF model (it
>> worked perfectly with 2.0).
>> But the error message is so unhandy that no one could tell what
>> exactly the cause is. At least the feature structure should be also
>> named.
>> Also I am not sure why the EMF type "CUSTOM" is used. I am not using
>> any special in my EMF models.
>>
>> Regards,
>> Kai]]>Eike Stepper2009-07-23T17:11:00-00:00Re: [CDO] No suitable mapping found from EMF type CUSTOM to DB type DBType
https://www.eclipse.org/forums/index.php/mv/msg/136804/431755/#msg_431755
> Ok, here lies the problem.
> My model has indeed a custom field (EJavaObject), but I never commit
> any of those objects with this feature structure into the database.
> CDO 2.0 could live with that and was never interested in that never
> persisted object. In contrast CDO CVS Head now is interested in those
> objects when setting up the database and throws the below exception.
> In my opinion we should make CDO Head behave as CDO 2.0. Only do
> mappings when needed.
Can you file a bugzilla so that we can discuss that with Stefan?
>
> Regards,
> Kai
>
>
> Kai Schlamp wrote:
>> Forgot the trace:
>>
>> Rollback in DBStore: java.lang.IllegalArgumentException: No suitable
>> mapping found from EMF type CUSTOM to DB type DBType
>> at
>> org.eclipse.emf.cdo.server.internal.db.mapping.TypeMappingFa ctory.createTypeMapping(TypeMappingFactory.java:255)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.createValueMapping(AbstractMappingStrategy.java:3 88)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ab stractHorizontalClassMapping.createValueMappings(AbstractHor izontalClassMapping.java:119)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ab stractHorizontalClassMapping.initFeatures(AbstractHorizontal ClassMapping.java:107)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ab stractHorizontalClassMapping. <init>(AbstractHorizontalClassMapping.java:76)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ho rizontalNonAuditClassMapping. <init>(HorizontalNonAuditClassMapping.java:90)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ho rizontalNonAuditMappingStrategy.doCreateClassMapping(Horizon talNonAuditMappingStrategy.java:29)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.createClassMapping(AbstractMappingStrategy.java:3 55)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.mapClasses(AbstractMappingStrategy.java:325)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.mapPackageInfos(AbstractMappingStrategy.java:314)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.mapPackageUnits(AbstractMappingStrategy.java:336)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.createMapping(AbstractMappingStrategy.java:297)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.write PackageUnits(DBStoreAccessor.java:501)
>>
>> at
>> org.eclipse.emf.cdo.spi.server.StoreAccessor.write(StoreAcce ssor.java:132)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.acces s$4(DBStoreAccessor.java:1)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor$1.run Loop(DBStoreAccessor.java:80)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor$1.run Loop(DBStoreAccessor.java:1)
>>
>> at
>> org.eclipse.net4j.util.om.monitor.ProgressDistributor.run(Pr ogressDistributor.java:96)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.write (DBStoreAccessor.java:299)
>>
>> at
>> org.eclipse.emf.cdo.internal.server.TransactionCommitContext Impl.write(TransactionCommitContextImpl.java:273)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication$1.runLoop(CommitTransactionIndication.jav a:72)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication$1.runLoop(CommitTransactionIndication.jav a:1)
>>
>> at
>> org.eclipse.net4j.util.om.monitor.ProgressDistributor.run(Pr ogressDistributor.java:96)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication.indicatingCommit(CommitTransactionIndicat ion.java:280)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication.indicating(CommitTransactionIndication.ja va:173)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication.indicating(CommitTransactionIndication.ja va:139)
>>
>> at
>> org.eclipse.net4j.signal.IndicationWithMonitoring.indicating (IndicationWithMonitoring.java:84)
>>
>> at
>> org.eclipse.net4j.signal.IndicationWithResponse.doExtendedIn put(IndicationWithResponse.java:90)
>>
>> at org.eclipse.net4j.signal.Signal.doInput(Signal.java:312)
>> at
>> org.eclipse.net4j.signal.IndicationWithResponse.execute(Indi cationWithResponse.java:63)
>>
>> at
>> org.eclipse.net4j.signal.IndicationWithMonitoring.execute(In dicationWithMonitoring.java:63)
>>
>> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:239)
>> at org.eclipse.net4j.signal.Signal.run(Signal.java:147)
>> at
>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Threa dPoolExecutor.java:886)
>>
>> at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo lExecutor.java:908)
>>
>> at java.lang.Thread.run(Thread.java:619)
>>
>> at
>> org.pubcurator.core.managers.ServerManager.connectToServer(S erverManager.java:228)
>>
>> at
>> org.pubcurator.core.managers.ServerManager.connectToLocalSer ver(ServerManager.java:186)
>>
>> at
>> org.pubcurator.core.ApplicationWorkbenchAdvisor$1$1.run(Appl icationWorkbenchAdvisor.java:87)
>>
>> at
>> org.eclipse.jface.operation.ModalContext$ModalContextThread. run(ModalContext.java:121)
>>
>>
>>
>> Kai Schlamp wrote:
>>> As I mentioned in my previous message I switched from CDO 2.0 to the
>>> current CVS Head as target for my RCP app.
>>> When starting my app I get the below exception.
>>> So it seems the mapping doen't like some type in my EMF model (it
>>> worked perfectly with 2.0).
>>> But the error message is so unhandy that no one could tell what
>>> exactly the cause is. At least the feature structure should be also
>>> named.
>>> Also I am not sure why the EMF type "CUSTOM" is used. I am not using
>>> any special in my EMF models.
>>>
>>> Regards,
>>> Kai]]>Eike Stepper2009-07-23T17:11:30-00:00Re: [CDO] No suitable mapping found from EMF type CUSTOM to DB type DBType
https://www.eclipse.org/forums/index.php/mv/msg/136804/431756/#msg_431756
> Shouldn't the field be transient?
>
Indeed, that's what I think, too.
> Tom
>
> Kai Schlamp schrieb:
>
>> Ok, here lies the problem.
>> My model has indeed a custom field (EJavaObject), but I never commit any
>> of those objects with this feature structure into the database.
>> CDO 2.0 could live with that and was never interested in that never
>> persisted object. In contrast CDO CVS Head now is interested in those
>> objects when setting up the database and throws the below exception.
>> In my opinion we should make CDO Head behave as CDO 2.0. Only do
>> mappings when needed.
>>
>> Regards,
>> Kai
>>
>>
>> Kai Schlamp wrote:
>>
>>> Forgot the trace:
>>>
>>> Rollback in DBStore: java.lang.IllegalArgumentException: No suitable
>>> mapping found from EMF type CUSTOM to DB type DBType
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.mapping.TypeMappingFa ctory.createTypeMapping(TypeMappingFactory.java:255)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.createValueMapping(AbstractMappingStrategy.java:3 88)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ab stractHorizontalClassMapping.createValueMappings(AbstractHor izontalClassMapping.java:119)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ab stractHorizontalClassMapping.initFeatures(AbstractHorizontal ClassMapping.java:107)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ab stractHorizontalClassMapping. <init>(AbstractHorizontalClassMapping.java:76)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ho rizontalNonAuditClassMapping. <init>(HorizontalNonAuditClassMapping.java:90)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ho rizontalNonAuditMappingStrategy.doCreateClassMapping(Horizon talNonAuditMappingStrategy.java:29)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.createClassMapping(AbstractMappingStrategy.java:3 55)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.mapClasses(AbstractMappingStrategy.java:325)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.mapPackageInfos(AbstractMappingStrategy.java:314)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.mapPackageUnits(AbstractMappingStrategy.java:336)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.createMapping(AbstractMappingStrategy.java:297)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.write PackageUnits(DBStoreAccessor.java:501)
>>>
>>> at
>>> org.eclipse.emf.cdo.spi.server.StoreAccessor.write(StoreAcce ssor.java:132)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.acces s$4(DBStoreAccessor.java:1)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor$1.run Loop(DBStoreAccessor.java:80)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor$1.run Loop(DBStoreAccessor.java:1)
>>>
>>> at
>>> org.eclipse.net4j.util.om.monitor.ProgressDistributor.run(Pr ogressDistributor.java:96)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.write (DBStoreAccessor.java:299)
>>>
>>> at
>>> org.eclipse.emf.cdo.internal.server.TransactionCommitContext Impl.write(TransactionCommitContextImpl.java:273)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication$1.runLoop(CommitTransactionIndication.jav a:72)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication$1.runLoop(CommitTransactionIndication.jav a:1)
>>>
>>> at
>>> org.eclipse.net4j.util.om.monitor.ProgressDistributor.run(Pr ogressDistributor.java:96)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication.indicatingCommit(CommitTransactionIndicat ion.java:280)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication.indicating(CommitTransactionIndication.ja va:173)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication.indicating(CommitTransactionIndication.ja va:139)
>>>
>>> at
>>> org.eclipse.net4j.signal.IndicationWithMonitoring.indicating (IndicationWithMonitoring.java:84)
>>>
>>> at
>>> org.eclipse.net4j.signal.IndicationWithResponse.doExtendedIn put(IndicationWithResponse.java:90)
>>>
>>> at org.eclipse.net4j.signal.Signal.doInput(Signal.java:312)
>>> at
>>> org.eclipse.net4j.signal.IndicationWithResponse.execute(Indi cationWithResponse.java:63)
>>>
>>> at
>>> org.eclipse.net4j.signal.IndicationWithMonitoring.execute(In dicationWithMonitoring.java:63)
>>>
>>> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:239)
>>> at org.eclipse.net4j.signal.Signal.run(Signal.java:147)
>>> at
>>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Threa dPoolExecutor.java:886)
>>>
>>> at
>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo lExecutor.java:908)
>>>
>>> at java.lang.Thread.run(Thread.java:619)
>>>
>>> at
>>> org.pubcurator.core.managers.ServerManager.connectToServer(S erverManager.java:228)
>>>
>>> at
>>> org.pubcurator.core.managers.ServerManager.connectToLocalSer ver(ServerManager.java:186)
>>>
>>> at
>>> org.pubcurator.core.ApplicationWorkbenchAdvisor$1$1.run(Appl icationWorkbenchAdvisor.java:87)
>>>
>>> at
>>> org.eclipse.jface.operation.ModalContext$ModalContextThread. run(ModalContext.java:121)
>>>
>>>
>>>
>>> Kai Schlamp wrote:
>>>
>>>> As I mentioned in my previous message I switched from CDO 2.0 to the
>>>> current CVS Head as target for my RCP app.
>>>> When starting my app I get the below exception.
>>>> So it seems the mapping doen't like some type in my EMF model (it
>>>> worked perfectly with 2.0).
>>>> But the error message is so unhandy that no one could tell what
>>>> exactly the cause is. At least the feature structure should be also
>>>> named.
>>>> Also I am not sure why the EMF type "CUSTOM" is used. I am not using
>>>> any special in my EMF models.
>>>>
>>>> Regards,
>>>> Kai
>>>>]]>Eike Stepper2009-07-23T17:12:12-00:00Re: [CDO] No suitable mapping found from EMF type CUSTOM to DB type DBType
https://www.eclipse.org/forums/index.php/mv/msg/136804/431757/#msg_431757
> Tom, you are correct. Transient indeed works (I already solved it that
> way). But in my opinion it's more a conceptual question of how CDO
> works. Why does CDO bother with type mappings when nothing is intended
> to be committed. But I am still not sure for myself ... is it intended
> or even a feature?!
I'd say it's intended. From a conceptual point of view it sounds odd to
allow things that are known to violate assumptions and hope that it will
not occur. Technically it's next to impossible to lazily create missing
mappings. SQL does not seem to define a standard way how to execute DDL.
Some vendors do it in the normal transaction, some do it outside, others
implicitely commit the ongoing transaction before and after DDL.
> As I said, it behave differently when using CDO 2.0 that's why it
> attracted my attention.
Maybe it's related with different handling of the mapping inside the
DBStore. Stefan, is there something that pops into your mind?
>
> Regards,
> Kai
>
> Tom Schindl wrote:
>> Shouldn't the field be transient?
>>
>> Tom
>>
>> Kai Schlamp schrieb:
>>> Ok, here lies the problem.
>>> My model has indeed a custom field (EJavaObject), but I never commit
>>> any
>>> of those objects with this feature structure into the database.
>>> CDO 2.0 could live with that and was never interested in that never
>>> persisted object. In contrast CDO CVS Head now is interested in those
>>> objects when setting up the database and throws the below exception.
>>> In my opinion we should make CDO Head behave as CDO 2.0. Only do
>>> mappings when needed.
>>>
>>> Regards,
>>> Kai
>>>
>>>
>>> Kai Schlamp wrote:
>>>> Forgot the trace:
>>>>
>>>> Rollback in DBStore: java.lang.IllegalArgumentException: No suitable
>>>> mapping found from EMF type CUSTOM to DB type DBType
>>>> at
>>>> org.eclipse.emf.cdo.server.internal.db.mapping.TypeMappingFa ctory.createTypeMapping(TypeMappingFactory.java:255)
>>>>
>>>>
>>>> at
>>>> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.createValueMapping(AbstractMappingStrategy.java:3 88)
>>>>
>>>>
>>>> at
>>>> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ab stractHorizontalClassMapping.createValueMappings(AbstractHor izontalClassMapping.java:119)
>>>>
>>>>
>>>> at
>>>> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ab stractHorizontalClassMapping.initFeatures(AbstractHorizontal ClassMapping.java:107)
>>>>
>>>>
>>>> at
>>>> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ab stractHorizontalClassMapping. <init>(AbstractHorizontalClassMapping.java:76)
>>>>
>>>>
>>>> at
>>>> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ho rizontalNonAuditClassMapping. <init>(HorizontalNonAuditClassMapping.java:90)
>>>>
>>>>
>>>> at
>>>> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ho rizontalNonAuditMappingStrategy.doCreateClassMapping(Horizon talNonAuditMappingStrategy.java:29)
>>>>
>>>>
>>>> at
>>>> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.createClassMapping(AbstractMappingStrategy.java:3 55)
>>>>
>>>>
>>>> at
>>>> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.mapClasses(AbstractMappingStrategy.java:325)
>>>>
>>>>
>>>> at
>>>> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.mapPackageInfos(AbstractMappingStrategy.java:314)
>>>>
>>>>
>>>> at
>>>> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.mapPackageUnits(AbstractMappingStrategy.java:336)
>>>>
>>>>
>>>> at
>>>> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.createMapping(AbstractMappingStrategy.java:297)
>>>>
>>>>
>>>> at
>>>> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.write PackageUnits(DBStoreAccessor.java:501)
>>>>
>>>>
>>>> at
>>>> org.eclipse.emf.cdo.spi.server.StoreAccessor.write(StoreAcce ssor.java:132)
>>>>
>>>>
>>>> at
>>>> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.acces s$4(DBStoreAccessor.java:1)
>>>>
>>>>
>>>> at
>>>> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor$1.run Loop(DBStoreAccessor.java:80)
>>>>
>>>>
>>>> at
>>>> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor$1.run Loop(DBStoreAccessor.java:1)
>>>>
>>>>
>>>> at
>>>> org.eclipse.net4j.util.om.monitor.ProgressDistributor.run(Pr ogressDistributor.java:96)
>>>>
>>>>
>>>> at
>>>> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.write (DBStoreAccessor.java:299)
>>>>
>>>>
>>>> at
>>>> org.eclipse.emf.cdo.internal.server.TransactionCommitContext Impl.write(TransactionCommitContextImpl.java:273)
>>>>
>>>>
>>>> at
>>>> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication$1.runLoop(CommitTransactionIndication.jav a:72)
>>>>
>>>>
>>>> at
>>>> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication$1.runLoop(CommitTransactionIndication.jav a:1)
>>>>
>>>>
>>>> at
>>>> org.eclipse.net4j.util.om.monitor.ProgressDistributor.run(Pr ogressDistributor.java:96)
>>>>
>>>>
>>>> at
>>>> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication.indicatingCommit(CommitTransactionIndicat ion.java:280)
>>>>
>>>>
>>>> at
>>>> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication.indicating(CommitTransactionIndication.ja va:173)
>>>>
>>>>
>>>> at
>>>> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication.indicating(CommitTransactionIndication.ja va:139)
>>>>
>>>>
>>>> at
>>>> org.eclipse.net4j.signal.IndicationWithMonitoring.indicating (IndicationWithMonitoring.java:84)
>>>>
>>>>
>>>> at
>>>> org.eclipse.net4j.signal.IndicationWithResponse.doExtendedIn put(IndicationWithResponse.java:90)
>>>>
>>>>
>>>> at org.eclipse.net4j.signal.Signal.doInput(Signal.java:312)
>>>> at
>>>> org.eclipse.net4j.signal.IndicationWithResponse.execute(Indi cationWithResponse.java:63)
>>>>
>>>>
>>>> at
>>>> org.eclipse.net4j.signal.IndicationWithMonitoring.execute(In dicationWithMonitoring.java:63)
>>>>
>>>>
>>>> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:239)
>>>> at org.eclipse.net4j.signal.Signal.run(Signal.java:147)
>>>> at
>>>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Threa dPoolExecutor.java:886)
>>>>
>>>>
>>>> at
>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo lExecutor.java:908)
>>>>
>>>>
>>>> at java.lang.Thread.run(Thread.java:619)
>>>>
>>>> at
>>>> org.pubcurator.core.managers.ServerManager.connectToServer(S erverManager.java:228)
>>>>
>>>>
>>>> at
>>>> org.pubcurator.core.managers.ServerManager.connectToLocalSer ver(ServerManager.java:186)
>>>>
>>>>
>>>> at
>>>> org.pubcurator.core.ApplicationWorkbenchAdvisor$1$1.run(Appl icationWorkbenchAdvisor.java:87)
>>>>
>>>>
>>>> at
>>>> org.eclipse.jface.operation.ModalContext$ModalContextThread. run(ModalContext.java:121)
>>>>
>>>>
>>>>
>>>>
>>>> Kai Schlamp wrote:
>>>>> As I mentioned in my previous message I switched from CDO 2.0 to the
>>>>> current CVS Head as target for my RCP app.
>>>>> When starting my app I get the below exception.
>>>>> So it seems the mapping doen't like some type in my EMF model (it
>>>>> worked perfectly with 2.0).
>>>>> But the error message is so unhandy that no one could tell what
>>>>> exactly the cause is. At least the feature structure should be also
>>>>> named.
>>>>> Also I am not sure why the EMF type "CUSTOM" is used. I am not using
>>>>> any special in my EMF models.
>>>>>
>>>>> Regards,
>>>>> Kai]]>Eike Stepper2009-07-23T17:17:04-00:00Re: [CDO] No suitable mapping found from EMF type CUSTOM to DB type DBType
https://www.eclipse.org/forums/index.php/mv/msg/136804/431781/#msg_431781
> Kai Schlamp schrieb:
>> Ok, here lies the problem.
>> My model has indeed a custom field (EJavaObject), but I never commit
>> any of those objects with this feature structure into the database.
>> CDO 2.0 could live with that and was never interested in that never
>> persisted object. In contrast CDO CVS Head now is interested in those
>> objects when setting up the database and throws the below exception.
>> In my opinion we should make CDO Head behave as CDO 2.0. Only do
>> mappings when needed.
> Can you file a bugzilla so that we can discuss that with Stefan?
But it's not only the type mapping, it's also the way the complete database is created by the DB
store. In CDO 2.0 a database table was created on demand (if something was commited). With CDO Head
all database tables are created the first time the database is accessed.
The problem is that I mostly mix my models with classes that should be persisted to database and
classes that are not intendet for persistence. Now with CDO Head many tables are created that are
never used.
May we should add an annotation option to suppress a table creation for a specific class.
What do you think?
Discussion here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=284680
>
> Cheers
> /Eike
>
> ----
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
>> Regards,
>> Kai
>>
>>
>> Kai Schlamp wrote:
>>> Forgot the trace:
>>>
>>> Rollback in DBStore: java.lang.IllegalArgumentException: No suitable
>>> mapping found from EMF type CUSTOM to DB type DBType
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.mapping.TypeMappingFa ctory.createTypeMapping(TypeMappingFactory.java:255)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.createValueMapping(AbstractMappingStrategy.java:3 88)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ab stractHorizontalClassMapping.createValueMappings(AbstractHor izontalClassMapping.java:119)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ab stractHorizontalClassMapping.initFeatures(AbstractHorizontal ClassMapping.java:107)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ab stractHorizontalClassMapping. <init>(AbstractHorizontalClassMapping.java:76)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ho rizontalNonAuditClassMapping. <init>(HorizontalNonAuditClassMapping.java:90)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ho rizontalNonAuditMappingStrategy.doCreateClassMapping(Horizon talNonAuditMappingStrategy.java:29)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.createClassMapping(AbstractMappingStrategy.java:3 55)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.mapClasses(AbstractMappingStrategy.java:325)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.mapPackageInfos(AbstractMappingStrategy.java:314)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.mapPackageUnits(AbstractMappingStrategy.java:336)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.createMapping(AbstractMappingStrategy.java:297)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.write PackageUnits(DBStoreAccessor.java:501)
>>>
>>> at
>>> org.eclipse.emf.cdo.spi.server.StoreAccessor.write(StoreAcce ssor.java:132)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.acces s$4(DBStoreAccessor.java:1)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor$1.run Loop(DBStoreAccessor.java:80)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor$1.run Loop(DBStoreAccessor.java:1)
>>>
>>> at
>>> org.eclipse.net4j.util.om.monitor.ProgressDistributor.run(Pr ogressDistributor.java:96)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.write (DBStoreAccessor.java:299)
>>>
>>> at
>>> org.eclipse.emf.cdo.internal.server.TransactionCommitContext Impl.write(TransactionCommitContextImpl.java:273)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication$1.runLoop(CommitTransactionIndication.jav a:72)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication$1.runLoop(CommitTransactionIndication.jav a:1)
>>>
>>> at
>>> org.eclipse.net4j.util.om.monitor.ProgressDistributor.run(Pr ogressDistributor.java:96)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication.indicatingCommit(CommitTransactionIndicat ion.java:280)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication.indicating(CommitTransactionIndication.ja va:173)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication.indicating(CommitTransactionIndication.ja va:139)
>>>
>>> at
>>> org.eclipse.net4j.signal.IndicationWithMonitoring.indicating (IndicationWithMonitoring.java:84)
>>>
>>> at
>>> org.eclipse.net4j.signal.IndicationWithResponse.doExtendedIn put(IndicationWithResponse.java:90)
>>>
>>> at org.eclipse.net4j.signal.Signal.doInput(Signal.java:312)
>>> at
>>> org.eclipse.net4j.signal.IndicationWithResponse.execute(Indi cationWithResponse.java:63)
>>>
>>> at
>>> org.eclipse.net4j.signal.IndicationWithMonitoring.execute(In dicationWithMonitoring.java:63)
>>>
>>> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:239)
>>> at org.eclipse.net4j.signal.Signal.run(Signal.java:147)
>>> at
>>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Threa dPoolExecutor.java:886)
>>>
>>> at
>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo lExecutor.java:908)
>>>
>>> at java.lang.Thread.run(Thread.java:619)
>>>
>>> at
>>> org.pubcurator.core.managers.ServerManager.connectToServer(S erverManager.java:228)
>>>
>>> at
>>> org.pubcurator.core.managers.ServerManager.connectToLocalSer ver(ServerManager.java:186)
>>>
>>> at
>>> org.pubcurator.core.ApplicationWorkbenchAdvisor$1$1.run(Appl icationWorkbenchAdvisor.java:87)
>>>
>>> at
>>> org.eclipse.jface.operation.ModalContext$ModalContextThread. run(ModalContext.java:121)
>>>
>>>
>>>
>>> Kai Schlamp wrote:
>>>> As I mentioned in my previous message I switched from CDO 2.0 to the
>>>> current CVS Head as target for my RCP app.
>>>> When starting my app I get the below exception.
>>>> So it seems the mapping doen't like some type in my EMF model (it
>>>> worked perfectly with 2.0).
>>>> But the error message is so unhandy that no one could tell what
>>>> exactly the cause is. At least the feature structure should be also
>>>> named.
>>>> Also I am not sure why the EMF type "CUSTOM" is used. I am not using
>>>> any special in my EMF models.
>>>>
>>>> Regards,
>>>> Kai]]>Kai Schlamp2009-07-26T17:30:42-00:00Re: [CDO] No suitable mapping found from EMF type CUSTOM to DB type DBType
https://www.eclipse.org/forums/index.php/mv/msg/136804/435435/#msg_435435
(I don't know if you're getting it for the same reason, but maybe it will
help):
I am using an xsd based model and the error occurs on the first String
typed feature in a class. The problem that occurs is the following:
CDOModelUtil.getType(EClassifier classifier) is used to determin the type
which looks like that:
public static CDOType getType(EClassifier classifier)
{
if (classifier instanceof EClass)
{
return CDOType.OBJECT;
}
if (classifier instanceof EEnum)
{
return CDOType.ENUM_ORDINAL;
}
if (isCorePackage(classifier.getEPackage()))
{
EDataType eDataType = (EDataType)classifier;
CDOType type = getCoreType(eDataType);
if (type != null)
{
return type;
}
}
Possible solution: Add type mappings for XMLType types
I'm not really sure, if I have interpreted that correctly, so I haven't
yet created a bugzilla entry. Please let me know what you think about it.
regards,
Chris]]>Christopher Albert2009-07-30T21:00:31-00:00Re: [CDO] No suitable mapping found from EMF type CUSTOM to DB type DBType
https://www.eclipse.org/forums/index.php/mv/msg/136804/435643/#msg_435643
> ...
> The problem is that neither of the three condition is fulfilled because
> String is a base type and no EClass BUT in the package
> http://www.eclipse.org/emf/2003/XMLType. isCorePackage() returns only true
> if it's http://www.eclipse.org/emf/2002/Ecore (and mappings are only
> defined for those types).
> Possible solution: Add type mappings for XMLType types
> I'm not really sure, if I have interpreted that correctly, so I haven't
> yet created a bugzilla entry. Please let me know what you think about it.
Update: I forgot to generate an xsd-ecore mapping file, when I did that,
the problem disappeared as the types are now mapped to core types.]]>Christopher Albert2009-07-30T21:22:03-00:00Re: [CDO] No suitable mapping found from EMF type CUSTOM to DB type DBType
https://www.eclipse.org/forums/index.php/mv/msg/136804/436717/#msg_436717
Good that you found your problem. I only run into that problem when using non EMF data types. Those
must be set to transient as CDO can't know how to store them.
Regards,
Kai
Christopher Albert wrote:
> Christopher Albert wrote:
>
>> ...
>> The problem is that neither of the three condition is fulfilled
>> because String is a base type and no EClass BUT in the package
>> http://www.eclipse.org/emf/2003/XMLType. isCorePackage() returns only
>> true if it's http://www.eclipse.org/emf/2002/Ecore (and mappings are
>> only defined for those types).
>
>> Possible solution: Add type mappings for XMLType types
>
>> I'm not really sure, if I have interpreted that correctly, so I
>> haven't yet created a bugzilla entry. Please let me know what you
>> think about it.
>
> Update: I forgot to generate an xsd-ecore mapping file, when I did that,
> the problem disappeared as the types are now mapped to core types.
>
>]]>Kai Schlamp2009-07-31T00:10:16-00:00Re: [CDO] No suitable mapping found from EMF type CUSTOM to DB type DBType
https://www.eclipse.org/forums/index.php/mv/msg/136804/439224/#msg_439224
That sounds like a regression in CDO. Unknown EDataTypes should be
represented by CDOType.CUSTOM. Can you file a bugzilla?
Kai Schlamp schrieb:
> Hi Christopher.
>
> Good that you found your problem. I only run into that problem when
> using non EMF data types. Those must be set to transient as CDO can't
> know how to store them.
>
> Regards,
> Kai
>
> Christopher Albert wrote:
>> Christopher Albert wrote:
>>
>>> ...
>>> The problem is that neither of the three condition is fulfilled
>>> because String is a base type and no EClass BUT in the package
>>> http://www.eclipse.org/emf/2003/XMLType. isCorePackage() returns
>>> only true if it's http://www.eclipse.org/emf/2002/Ecore (and
>>> mappings are only defined for those types).
>>
>>> Possible solution: Add type mappings for XMLType types
>>
>>> I'm not really sure, if I have interpreted that correctly, so I
>>> haven't yet created a bugzilla entry. Please let me know what you
>>> think about it.
>>
>> Update: I forgot to generate an xsd-ecore mapping file, when I did
>> that, the problem disappeared as the types are now mapped to core types.
>>
>>]]>Eike Stepper2009-07-31T05:48:36-00:00Re: [CDO] No suitable mapping found from EMF type CUSTOM to DB type DBType
https://www.eclipse.org/forums/index.php/mv/msg/136804/441010/#msg_441010
> Christopher, Kai,
>
> That sounds like a regression in CDO. Unknown EDataTypes should be
> represented by CDOType.CUSTOM. Can you file a bugzilla?
I think that those are represented by CDOType.CUSTOM, but the DB Store simply doesn't know what to
do with that type (and throws an exception). Or do you mean something other?
>
> Cheers
> /Eike
>
> ----
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
>
> Kai Schlamp schrieb:
>> Hi Christopher.
>>
>> Good that you found your problem. I only run into that problem when
>> using non EMF data types. Those must be set to transient as CDO can't
>> know how to store them.
>>
>> Regards,
>> Kai
>>
>> Christopher Albert wrote:
>>> Christopher Albert wrote:
>>>
>>>> ...
>>>> The problem is that neither of the three condition is fulfilled
>>>> because String is a base type and no EClass BUT in the package
>>>> http://www.eclipse.org/emf/2003/XMLType. isCorePackage() returns
>>>> only true if it's http://www.eclipse.org/emf/2002/Ecore (and
>>>> mappings are only defined for those types).
>>>> Possible solution: Add type mappings for XMLType types
>>>> I'm not really sure, if I have interpreted that correctly, so I
>>>> haven't yet created a bugzilla entry. Please let me know what you
>>>> think about it.
>>> Update: I forgot to generate an xsd-ecore mapping file, when I did
>>> that, the problem disappeared as the types are now mapped to core types.
>>>
>>>]]>Kai Schlamp2009-07-31T09:22:57-00:00Re: [CDO] No suitable mapping found from EMF type CUSTOM to DB type DBType
https://www.eclipse.org/forums/index.php/mv/msg/136804/441011/#msg_441011
> Eike Stepper wrote:
>> Christopher, Kai,
>>
>> That sounds like a regression in CDO. Unknown EDataTypes should be
>> represented by CDOType.CUSTOM. Can you file a bugzilla?
>
> I think that those are represented by CDOType.CUSTOM, but the DB Store
> simply doesn't know what to do with that type (and throws an
> exception). Or do you mean something other?
Probably I just lost track in this long thread. If there is a problem
anywhere please file a bugzilla with a stack trace ;-)
>
>>
>> Cheers
>> /Eike
>>
>> ----
>> http://thegordian.blogspot.com
>> http://twitter.com/eikestepper
>>
>>
>>
>> Kai Schlamp schrieb:
>>> Hi Christopher.
>>>
>>> Good that you found your problem. I only run into that problem when
>>> using non EMF data types. Those must be set to transient as CDO can't
>>> know how to store them.
>>>
>>> Regards,
>>> Kai
>>>
>>> Christopher Albert wrote:
>>>> Christopher Albert wrote:
>>>>
>>>>> ...
>>>>> The problem is that neither of the three condition is fulfilled
>>>>> because String is a base type and no EClass BUT in the package
>>>>> http://www.eclipse.org/emf/2003/XMLType. isCorePackage() returns
>>>>> only true if it's http://www.eclipse.org/emf/2002/Ecore (and
>>>>> mappings are only defined for those types).
>>>>> Possible solution: Add type mappings for XMLType types
>>>>> I'm not really sure, if I have interpreted that correctly, so I
>>>>> haven't yet created a bugzilla entry. Please let me know what you
>>>>> think about it.
>>>> Update: I forgot to generate an xsd-ecore mapping file, when I did
>>>> that, the problem disappeared as the types are now mapped to core
>>>> types.
>>>>
>>>>]]>Eike Stepper2009-07-31T09:34:36-00:00Re: [CDO] No suitable mapping found from EMF type CUSTOM to DB type DBType
https://www.eclipse.org/forums/index.php/mv/msg/136804/441057/#msg_441057
I don't think there's a problem because one simply can't persist an
arbitrary JavaObject whether it is CDO, Teneo or the "simple" XMI
persistance.
IMHO CDO is completely right in throwing an Exception if someone to has
a none transient arbitrary JavaObject in his/her model.
Tom
Eike Stepper schrieb:
> Kai Schlamp schrieb:
>> Eike Stepper wrote:
>>> Christopher, Kai,
>>>
>>> That sounds like a regression in CDO. Unknown EDataTypes should be
>>> represented by CDOType.CUSTOM. Can you file a bugzilla?
>> I think that those are represented by CDOType.CUSTOM, but the DB Store
>> simply doesn't know what to do with that type (and throws an
>> exception). Or do you mean something other?
> Probably I just lost track in this long thread. If there is a problem
> anywhere please file a bugzilla with a stack trace ;-)
>
> Cheers
> /Eike
>
> ----
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
>>> Cheers
>>> /Eike
>>>
>>> ----
>>> http://thegordian.blogspot.com
>>> http://twitter.com/eikestepper
>>>
>>>
>>>
>>> Kai Schlamp schrieb:
>>>> Hi Christopher.
>>>>
>>>> Good that you found your problem. I only run into that problem when
>>>> using non EMF data types. Those must be set to transient as CDO can't
>>>> know how to store them.
>>>>
>>>> Regards,
>>>> Kai
>>>>
>>>> Christopher Albert wrote:
>>>>> Christopher Albert wrote:
>>>>>
>>>>>> ...
>>>>>> The problem is that neither of the three condition is fulfilled
>>>>>> because String is a base type and no EClass BUT in the package
>>>>>> http://www.eclipse.org/emf/2003/XMLType. isCorePackage() returns
>>>>>> only true if it's http://www.eclipse.org/emf/2002/Ecore (and
>>>>>> mappings are only defined for those types).
>>>>>> Possible solution: Add type mappings for XMLType types
>>>>>> I'm not really sure, if I have interpreted that correctly, so I
>>>>>> haven't yet created a bugzilla entry. Please let me know what you
>>>>>> think about it.
>>>>> Update: I forgot to generate an xsd-ecore mapping file, when I did
>>>>> that, the problem disappeared as the types are now mapped to core
>>>>> types.
>>>>>
>>>>>]]>Thomas Schindl2009-07-31T09:39:35-00:00Re: [CDO] No suitable mapping found from EMF type CUSTOM to DB type DBType
https://www.eclipse.org/forums/index.php/mv/msg/136804/441195/#msg_441195
> Hi Eike,
>
> I don't think there's a problem because one simply can't persist an
> arbitrary JavaObject whether it is CDO, Teneo or the "simple" XMI
> persistance.
>
> IMHO CDO is completely right in throwing an Exception if someone to has
> a none transient arbitrary JavaObject in his/her model.
>
I'm not sure, though. This changed since we have the EPackage available
on the server. Now we have the EDataType on both client and server side
and we should use its String conversion methods. I know that the
CDOProtocol does that already via CDOType.CUSTOM. Maybe the DBStore did
not catch up with this change but continues to expect a String in the
CDORevision / delta. It that case we'd just need an additional
TypeMapping for CDOType.CUSTOM / String. Stefan?
> Tom
>
> Eike Stepper schrieb:
>
>> Kai Schlamp schrieb:
>>
>>> Eike Stepper wrote:
>>>
>>>> Christopher, Kai,
>>>>
>>>> That sounds like a regression in CDO. Unknown EDataTypes should be
>>>> represented by CDOType.CUSTOM. Can you file a bugzilla?
>>>>
>>> I think that those are represented by CDOType.CUSTOM, but the DB Store
>>> simply doesn't know what to do with that type (and throws an
>>> exception). Or do you mean something other?
>>>
>> Probably I just lost track in this long thread. If there is a problem
>> anywhere please file a bugzilla with a stack trace ;-)
>>
>> Cheers
>> /Eike
>>
>> ----
>> http://thegordian.blogspot.com
>> http://twitter.com/eikestepper
>>
>>
>>
>>>> Cheers
>>>> /Eike
>>>>
>>>> ----
>>>> http://thegordian.blogspot.com
>>>> http://twitter.com/eikestepper
>>>>
>>>>
>>>>
>>>> Kai Schlamp schrieb:
>>>>
>>>>> Hi Christopher.
>>>>>
>>>>> Good that you found your problem. I only run into that problem when
>>>>> using non EMF data types. Those must be set to transient as CDO can't
>>>>> know how to store them.
>>>>>
>>>>> Regards,
>>>>> Kai
>>>>>
>>>>> Christopher Albert wrote:
>>>>>
>>>>>> Christopher Albert wrote:
>>>>>>
>>>>>>
>>>>>>> ...
>>>>>>> The problem is that neither of the three condition is fulfilled
>>>>>>> because String is a base type and no EClass BUT in the package
>>>>>>> http://www.eclipse.org/emf/2003/XMLType. isCorePackage() returns
>>>>>>> only true if it's http://www.eclipse.org/emf/2002/Ecore (and
>>>>>>> mappings are only defined for those types).
>>>>>>> Possible solution: Add type mappings for XMLType types
>>>>>>> I'm not really sure, if I have interpreted that correctly, so I
>>>>>>> haven't yet created a bugzilla entry. Please let me know what you
>>>>>>> think about it.
>>>>>>>
>>>>>> Update: I forgot to generate an xsd-ecore mapping file, when I did
>>>>>> that, the problem disappeared as the types are now mapped to core
>>>>>> types.
>>>>>>
>>>>>>
>>>>>>]]>Eike Stepper2009-07-31T09:50:31-00:00Re: [CDO] No suitable mapping found from EMF type CUSTOM to DB type DBType
https://www.eclipse.org/forums/index.php/mv/msg/136804/441216/#msg_441216
Comments below...
Eike Stepper schrieb:
> Tom Schindl schrieb:
>
>> Hi Eike,
>>
>> I don't think there's a problem because one simply can't persist an
>> arbitrary JavaObject whether it is CDO, Teneo or the "simple" XMI
>> persistance.
>>
>> IMHO CDO is completely right in throwing an Exception if someone to has
>> a none transient arbitrary JavaObject in his/her model.
>>
>>
> I'm not sure, though. This changed since we have the EPackage available
> on the server. Now we have the EDataType on both client and server side
> and we should use its String conversion methods.
> I know that the
> CDOProtocol does that already via CDOType.CUSTOM. Maybe the DBStore did
> not catch up with this change but continues to expect a String in the
> CDORevision / delta. It that case we'd just need an additional
> TypeMapping for CDOType.CUSTOM / String. Stefan?
>
Yes and no. It is true that we have EDataType on the Server and it would
be no problem to create a TypeMapping which maps CUSTOM to String
calling the String conversion methods.
However, we don't have the *generated* or *user-defined* packages on the
server - we use reflective models there.
So, if a user creates a custom data type together with
createXYfromString)= and convertXYtoString() implementation, we still
don't have those on the server.
Even if the custom object would implement Serializable we still would
not be able to handle it on the server, because the custom class might
not be known on the server and, thus, can't be deserialized there.
So, if I have
public class Duck implements Serializable {
String name;
int gender;
}
and have a corresponding EDataType with instance class name = Duck, we
can't deserialize Duck on the server unless we put Duck into the server
class path.
I think, if we want to support CUSTOM-To-String mappings we need to do
the conversion where it can be done: on the client.
However, this might also be problematic, if different clients have
different mapping methods (e.g. due to versioning conflicts ...).
Cheers,
Stefan]]>Stefan Winkler2009-07-31T10:05:18-00:00Re: [CDO] No suitable mapping found from EMF type CUSTOM to DB type DBType
https://www.eclipse.org/forums/index.php/mv/msg/136804/441244/#msg_441244
>> I'm not sure, though. This changed since we have the EPackage available
>> on the server. Now we have the EDataType on both client and server side
>> and we should use its String conversion methods.
>> I know that the
>> CDOProtocol does that already via CDOType.CUSTOM. Maybe the DBStore did
>> not catch up with this change but continues to expect a String in the
>> CDORevision / delta. It that case we'd just need an additional
>> TypeMapping for CDOType.CUSTOM / String. Stefan?
>>
>>
> Yes and no. It is true that we have EDataType on the Server and it would
> be no problem to create a TypeMapping which maps CUSTOM to String
> calling the String conversion methods.
>
> However, we don't have the *generated* or *user-defined* packages on the
> server - we use reflective models there.
>
If they are deployed on the server they're now available. The new
CDOPackageRegistry is smart enough to handle this ;-)
Cheers
/Eike
---- http://thegordian.blogspot.com http://twitter.com/eikestepper]]>Eike Stepper2009-07-31T10:08:55-00:00Re: [CDO] No suitable mapping found from EMF type CUSTOM to DB type DBType
https://www.eclipse.org/forums/index.php/mv/msg/136804/442268/#msg_442268
newsgroup-standard ;-))
Eike Stepper schrieb:
> Stefan Winkler schrieb:
>
>>> I'm not sure, though. This changed since we have the EPackage available
>>> on the server. Now we have the EDataType on both client and server side
>>> and we should use its String conversion methods.
>>> I know that the
>>> CDOProtocol does that already via CDOType.CUSTOM. Maybe the DBStore did
>>> not catch up with this change but continues to expect a String in the
>>> CDORevision / delta. It that case we'd just need an additional
>>> TypeMapping for CDOType.CUSTOM / String. Stefan?
>>>
>>>
>>>
>> Yes and no. It is true that we have EDataType on the Server and it would
>> be no problem to create a TypeMapping which maps CUSTOM to String
>> calling the String conversion methods.
>>
>> However, we don't have the *generated* or *user-defined* packages on the
>> server - we use reflective models there.
>>
>>
> If they are deployed on the server they're now available. The new
> CDOPackageRegistry is smart enough to handle this ;-)
>
Hmm... ok in the one case the server has to be start-time configured and
in the other case it can run out of the box and custom types are
converted on the client.
I think both scenarios have their rationale.
E.g., in a bigger setting, where the server is shared among different
applications, the latter case would be more operations-friendly...
Cheers,
Stefan]]>Stefan Winkler2009-07-31T12:41:36-00:00Re: [CDO] No suitable mapping found from EMF type CUSTOM to DB type DBType
https://www.eclipse.org/forums/index.php/mv/msg/136804/451768/#msg_451768
>> CDOPackageRegistry is smart enough to handle this ;-)
>>
>>
> Hmm... ok in the one case the server has to be start-time configured and
> in the other case it can run out of the box and custom types are
> converted on the client.
> I think both scenarios have their rationale.
>
> E.g., in a bigger setting, where the server is shared among different
> applications, the latter case would be more operations-friendly...
Maybe we can do both:
if (packageUnit.getType == NATIVE)
revision.setValue(EDataType.createFromString(value));
else
revision.setValue(value);
The DBStore would have to do the opposite:
if (packageUnit.getType == NATIVE)
writeAttribute(EDataType.convertToString(revision.getValue() ));
else
writeAttribute(revision.getValue());