Home » Modeling » EMF » [CDO] No suitable mapping found from EMF type CUSTOM to DB type DBType
| [CDO] No suitable mapping found from EMF type CUSTOM to DB type DBType [message #431731] |
Thu, 23 July 2009 08:08  |
Eclipse User |
|
|
|
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
|
|
| | | | | | | | | | |
| 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 13:17  |
| Eclipse User |
|
|
|
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
|
|
| | | | | | | |
| 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 05:39 |
| Eclipse User |
|
|
|
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 05:50 |
| Eclipse User |
|
|
|
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.
>>>>>>
>>>>>>
>>>>>>
|
|
|
| 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 06:05 |
| Eclipse User |
|
|
|
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 #451768 is a reply to message #442268] |
Sat, 01 August 2009 07:32 |
| Eclipse User |
|
|
|
>> 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...
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());
Cheers
/Eike
----
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Goto Forum:
Current Time: Fri Jul 25 07:11:38 EDT 2025
Powered by FUDForum. Page generated in 0.10309 seconds |
Home