Home » Modeling » EMF » [CDO] No suitable mapping found from EMF type CUSTOM to DB type DBType
| | | | | | | |
| Re: [CDO] No suitable mapping found from EMF type CUSTOM to DB type DBType [message #431754 is a reply to message #431732] |
Thu, 23 July 2009 17:11   |
|
Kai,
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"...
Cheers
/Eike
----
http://thegordian.blogspot.com
http://twitter.com/eikestepper
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
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO] No suitable mapping found from EMF type CUSTOM to DB type DBType [message #431755 is a reply to message #431734] |
Thu, 23 July 2009 17:11 |
|
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?
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
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO] No suitable mapping found from EMF type CUSTOM to DB type DBType [message #431756 is a reply to message #431735] |
Thu, 23 July 2009 17:12 |
|
Tom Schindl schrieb:
> Shouldn't the field be transient?
>
Indeed, that's what I think, too.
Cheers
/Eike
----
http://thegordian.blogspot.com
http://twitter.com/eikestepper
> 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
>>>>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO] No suitable mapping found from EMF type CUSTOM to DB type DBType [message #431757 is a reply to message #431737] |
Thu, 23 July 2009 17:17 |
|
Kai Schlamp schrieb:
> 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?
Cheers
/Eike
----
http://thegordian.blogspot.com
http://twitter.com/eikestepper
>
> 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
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
| | | | | | |
| Re: [CDO] No suitable mapping found from EMF type CUSTOM to DB type DBType [message #441011 is a reply to message #441010] |
Fri, 31 July 2009 09:34 |
|
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.
>>>>
>>>>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO] No suitable mapping found from EMF type CUSTOM to DB type DBType [message #441057 is a reply to message #441011] |
Fri, 31 July 2009 09:39 |
 Thomas Schindl
Messages: 6651
Registered: July 2009 |
Senior Member |
|
|
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.
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.
>>>>>
>>>>>
|
|
|
| Re: [CDO] No suitable mapping found from EMF type CUSTOM to DB type DBType [message #441195 is a reply to message #441057] |
Fri, 31 July 2009 09:50 |
|
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?
Cheers
/Eike
----
http://thegordian.blogspot.com
http://twitter.com/eikestepper
> 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.
>>>>>>
>>>>>>
>>>>>>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO] No suitable mapping found from EMF type CUSTOM to DB type DBType [message #441216 is a reply to message #441195] |
Fri, 31 July 2009 10:05 |
Stefan Winkler
Messages: 307
Registered: July 2009
Location: Germany |
Senior Member |
|
|
Hi,
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
|
|
|
| Re: [CDO] No suitable mapping found from EMF type CUSTOM to DB type DBType [message #441244 is a reply to message #441216] |
Fri, 31 July 2009 10:08 |
|
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 ;-)
Cheers
/Eike
----
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
| | |
Goto Forum:
Current Time: Tue Apr 16 23:42:04 GMT 2024
Powered by FUDForum. Page generated in 3.50874 seconds |
] 
Search
Help
Register
Login
Home
