Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » [CDO][Teneo] Persistance of Custom EDataType
[CDO][Teneo] Persistance of Custom EDataType [message #663349] Mon, 04 April 2011 17:01 Go to next message
Eclipse UserFriend
Originally posted by: swt.magellium.fr

Hi list,

I'd like to store a custom EDataType in a database using CDO Hibernate
Store.
I started with the "hibernate store quickstart" which I managed to get
working using a PostgreSQL/PostGIS database.
Moreover, instead of the "PostgresqlDialect", I use a "PostgisDialect".
PostGIS is a PostgreSQL extension for spatial data.

Now, I'd like to add a new EAttribute to the EClass "Address", which
corresponds to the geographic coordinates (latitude/longitude) of the
address.
In order to do this, I defined a new EDataType named "Geometry".
It is mapped to the java type "com.vividsolutions.jts.geom.Geometry" (an
abstract class which stores geographic data such as points, polygons, etc.)
I also added to this EDataType, the following EAnnotation :
Source = teneo.jpa
Detail :
Key = appinfo
Value = @TypeDef(name="Geometry",
typeClass="org.hibernatespatial.GeometryUserType")

I modified the "QuickStartTest" class provided in the examples in order
to set a value to the geometry attribute of the "address".

When I run the test, I get the following exception on the server side :
Hibernate: insert into "address" (resource_id, container_id, version,
"name", "street", "city", "geometry", idcol) values (?, ?, ?, ?, ?, ?, ?, ?)
[ERROR] java.lang.String cannot be cast to
com.vividsolutions.jts.geom.Geometry
java.lang.ClassCastException: java.lang.String cannot be cast to
com.vividsolutions.jts.geom.Geometry
at
org.hibernatespatial.AbstractDBGeometryType.nullSafeSet(Abst ractDBGeometryType.java:152)
at
org.hibernatespatial.GeometryUserType.nullSafeSet(GeometryUs erType.java:186)
at org.hibernate.type.CustomType.nullSafeSet(CustomType.java:16 9)
at
org.hibernate.persister.entity.AbstractEntityPersister.dehyd rate(AbstractEntityPersister.java:2015)
at
org.hibernate.persister.entity.AbstractEntityPersister.inser t(AbstractEntityPersister.java:2261)
at
org.hibernate.persister.entity.AbstractEntityPersister.inser t(AbstractEntityPersister.java:2678)
at
org.hibernate.action.EntityInsertAction.execute(EntityInsert Action.java:79)
at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:27 9)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue. java:263)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue. java:167)
at
org.hibernate.event.def.AbstractFlushingEventListener.perfor mExecutions(AbstractFlushingEventListener.java:321)
at
org.hibernate.event.def.DefaultFlushEventListener.onFlush(De faultFlushEventListener.java:50)
at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1028)
at
org.eclipse.emf.cdo.server.internal.hibernate.HibernateStore Accessor.write(HibernateStoreAccessor.java:613)
at
org.eclipse.emf.cdo.internal.server.TransactionCommitContext .write(TransactionCommitContext.java:328)
at
org.eclipse.emf.cdo.spi.server.InternalCommitContext$1.runLo op(InternalCommitContext.java:35)
at
org.eclipse.emf.cdo.spi.server.InternalCommitContext$1.runLo op(InternalCommitContext.java: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:316)
at
org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication.indicating(CommitTransactionIndication.ja va:168)
at
org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication.indicating(CommitTransactionIndication.ja va:122)
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:315)
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:240)
at org.eclipse.net4j.signal.Signal.run(Signal.java:146)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unkno wn Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

I saw that CDO converts the geometry to a String when committing to the
server side.
It's just a supposition, but the problem seems to be somewhere in the
processing between CDO and Hibernate :
The String is not converted back to a Geometry
(com.vividsolutions.jts.geom.Geometry) object before it is handled by
hibernate (that is to say, by GeometryUserType)...
But I don't really know if it should...

Any advice would be appreciated :)
Thanks a lot in advance !

SWT
Re: [CDO][Teneo] Persistance of Custom EDataType [message #663577 is a reply to message #663349] Tue, 05 April 2011 16:44 Go to previous messageGo to next message
Martin Taal is currently offline Martin TaalFriend
Messages: 5468
Registered: July 2009
Senior Member
Hi SWT,
I guess that your GeometryUserType should be changed to handle strings and not the Geometry object you assume currently.
This string can be converted back to the actual object on the client I guess.

gr. Martin

On 04/04/2011 07:01 PM, SWT wrote:
> Hi list,
>
> I'd like to store a custom EDataType in a database using CDO Hibernate Store.
> I started with the "hibernate store quickstart" which I managed to get working using a PostgreSQL/PostGIS database.
> Moreover, instead of the "PostgresqlDialect", I use a "PostgisDialect".
> PostGIS is a PostgreSQL extension for spatial data.
>
> Now, I'd like to add a new EAttribute to the EClass "Address", which corresponds to the geographic coordinates
> (latitude/longitude) of the address.
> In order to do this, I defined a new EDataType named "Geometry".
> It is mapped to the java type "com.vividsolutions.jts.geom.Geometry" (an abstract class which stores geographic data
> such as points, polygons, etc.)
> I also added to this EDataType, the following EAnnotation :
> Source = teneo.jpa
> Detail :
> Key = appinfo
> Value = @TypeDef(name="Geometry", typeClass="org.hibernatespatial.GeometryUserType")
>
> I modified the "QuickStartTest" class provided in the examples in order to set a value to the geometry attribute of the
> "address".
>
> When I run the test, I get the following exception on the server side :
> Hibernate: insert into "address" (resource_id, container_id, version, "name", "street", "city", "geometry", idcol)
> values (?, ?, ?, ?, ?, ?, ?, ?)
> [ERROR] java.lang.String cannot be cast to com.vividsolutions.jts.geom.Geometry
> java.lang.ClassCastException: java.lang.String cannot be cast to com.vividsolutions.jts.geom.Geometry
> at org.hibernatespatial.AbstractDBGeometryType.nullSafeSet(Abst ractDBGeometryType.java:152)
> at org.hibernatespatial.GeometryUserType.nullSafeSet(GeometryUs erType.java:186)
> at org.hibernate.type.CustomType.nullSafeSet(CustomType.java:16 9)
> at org.hibernate.persister.entity.AbstractEntityPersister.dehyd rate(AbstractEntityPersister.java:2015)
> at org.hibernate.persister.entity.AbstractEntityPersister.inser t(AbstractEntityPersister.java:2261)
> at org.hibernate.persister.entity.AbstractEntityPersister.inser t(AbstractEntityPersister.java:2678)
> at org.hibernate.action.EntityInsertAction.execute(EntityInsert Action.java:79)
> at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:27 9)
> at org.hibernate.engine.ActionQueue.executeActions(ActionQueue. java:263)
> at org.hibernate.engine.ActionQueue.executeActions(ActionQueue. java:167)
> at org.hibernate.event.def.AbstractFlushingEventListener.perfor mExecutions(AbstractFlushingEventListener.java:321)
> at org.hibernate.event.def.DefaultFlushEventListener.onFlush(De faultFlushEventListener.java:50)
> at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1028)
> at org.eclipse.emf.cdo.server.internal.hibernate.HibernateStore Accessor.write(HibernateStoreAccessor.java:613)
> at org.eclipse.emf.cdo.internal.server.TransactionCommitContext .write(TransactionCommitContext.java:328)
> at org.eclipse.emf.cdo.spi.server.InternalCommitContext$1.runLo op(InternalCommitContext.java:35)
> at org.eclipse.emf.cdo.spi.server.InternalCommitContext$1.runLo op(InternalCommitContext.java: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:316)
>
> at
> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication.indicating(CommitTransactionIndication.ja va:168)
>
> at
> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication.indicating(CommitTransactionIndication.ja va:122)
>
> 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:315)
> 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:240)
> at org.eclipse.net4j.signal.Signal.run(Signal.java:146)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unkno wn Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
>
> I saw that CDO converts the geometry to a String when committing to the server side.
> It's just a supposition, but the problem seems to be somewhere in the processing between CDO and Hibernate :
> The String is not converted back to a Geometry (com.vividsolutions.jts.geom.Geometry) object before it is handled by
> hibernate (that is to say, by GeometryUserType)...
> But I don't really know if it should...
>
> Any advice would be appreciated :)
> Thanks a lot in advance !
>
> SWT


--

With Regards, Martin Taal

Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Cell: +31 (0)6 288 48 943
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org
Re: [CDO][Teneo] Persistance of Custom EDataType [message #663712 is a reply to message #663577] Wed, 06 April 2011 09:26 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: swt.magellium.fr

Hi Martin,

I can do that but this seems a bit problematic.
The "GeometryUserType" class is not mine, it's provided by "hibernate
spatial" (http://www.hibernatespatial.org/). It's a hibernate extension
project. So the GeometryUserType may change along with new releases of
hibernate spatial, but even with new releases of hibernate, etc.

For this time, I can use the source code of hibernate spatial to make it
work with CDO (using Strings) but for future versions, it's not really
ok to have to maintain a "CDO compatible version" of hibernate spatial...
Same issue may be raised for other "UserType" implementations provided
for Hibernate : these implementations won't work with CDO...

This is IMHO a general problem :
There may be numerous hibernate extensions for various "custom types".
Each "custom type" has a corresponding "UserType" implementation that
manipulates the corresponding java type and not the String type. (See
the UserType class javadoc :
http://docs.jboss.org/hibernate/core/3.5/api/org/hibernate/u sertype/UserType.html)

What you are suggesting is that for each of these custom types, a "CDO
UserType" implementation should be written, that does the same thing the
"standard UserType" (the one provided for "standard hibernate usage")
does but with String objects instead...


Stop me if I'm wrong :
Manipulating String objects is required because CDORevisions' objects
contain only serialized String values when committing a transaction from
the client to the server.
Once on the server side, the CDORevisions' objects must be stored in a
database (via hibernate or not). But the String values are values
serialized for transport from client to server. These are not values
serialized for database storage.

What I mean is that IMO, the steps of a commit should look like :

CLIENT OBJECTS WITH "OBJECT" VALUES
===== Serialization for transport ("convertToString") ===>
CLIENT OBJECTS WITH "STRING" VALUES
[ Transport to server through CDORevision ]
SERVER REVISION WITH "STRING" VALUES
===== Deserialization ("createFromString") ===>
SERVER REVISION WITH "OBJECT" VALUES
===== Database storage ===>
DATABASE UPDATED CONTENTS

In these steps, the "Database storage" step takes care of converting
objects to something that can be persisted. That is to say, this part
uses the "UserType" implementations when need.
But currently, in CDO, the "Deserialization" step does not exist (if I
do not miss something). So "UserType" implementations get String values
instead of object values.

This is quite like saying that the "convertToString" method is used to
serialize a value so that it can be stored in the database. To me, it's
not true... It should be meant to serialize value for transport only. Am
I wrong ?

Anyway, I'll try implementing a GeometryUserType which handles String
for the moment. But I'd really like to know if I'm right or wrong in
this analysis...
I hope I'm wrong and I missed something in CDO design. But if I'm right,
I hope this can be addressed because it sounds like an important issue
to me...

SWT

Le 05/04/2011 18:44, Martin Taal a écrit :
> Hi SWT,
> I guess that your GeometryUserType should be changed to handle strings
> and not the Geometry object you assume currently. This string can be
> converted back to the actual object on the client I guess.
>
> gr. Martin
>
> On 04/04/2011 07:01 PM, SWT wrote:
>> Hi list,
>>
>> I'd like to store a custom EDataType in a database using CDO Hibernate
>> Store.
>> I started with the "hibernate store quickstart" which I managed to get
>> working using a PostgreSQL/PostGIS database.
>> Moreover, instead of the "PostgresqlDialect", I use a "PostgisDialect".
>> PostGIS is a PostgreSQL extension for spatial data.
>>
>> Now, I'd like to add a new EAttribute to the EClass "Address", which
>> corresponds to the geographic coordinates
>> (latitude/longitude) of the address.
>> In order to do this, I defined a new EDataType named "Geometry".
>> It is mapped to the java type "com.vividsolutions.jts.geom.Geometry"
>> (an abstract class which stores geographic data
>> such as points, polygons, etc.)
>> I also added to this EDataType, the following EAnnotation :
>> Source = teneo.jpa
>> Detail :
>> Key = appinfo
>> Value = @TypeDef(name="Geometry",
>> typeClass="org.hibernatespatial.GeometryUserType")
>>
>> I modified the "QuickStartTest" class provided in the examples in
>> order to set a value to the geometry attribute of the
>> "address".
>>
>> When I run the test, I get the following exception on the server side :
>> Hibernate: insert into "address" (resource_id, container_id, version,
>> "name", "street", "city", "geometry", idcol)
>> values (?, ?, ?, ?, ?, ?, ?, ?)
>> [ERROR] java.lang.String cannot be cast to
>> com.vividsolutions.jts.geom.Geometry
>> java.lang.ClassCastException: java.lang.String cannot be cast to
>> com.vividsolutions.jts.geom.Geometry
>> at
>> org.hibernatespatial.AbstractDBGeometryType.nullSafeSet(Abst ractDBGeometryType.java:152)
>>
>> at
>> org.hibernatespatial.GeometryUserType.nullSafeSet(GeometryUs erType.java:186)
>>
>> at org.hibernate.type.CustomType.nullSafeSet(CustomType.java:16 9)
>> at
>> org.hibernate.persister.entity.AbstractEntityPersister.dehyd rate(AbstractEntityPersister.java:2015)
>>
>> at
>> org.hibernate.persister.entity.AbstractEntityPersister.inser t(AbstractEntityPersister.java:2261)
>>
>> at
>> org.hibernate.persister.entity.AbstractEntityPersister.inser t(AbstractEntityPersister.java:2678)
>>
>> at
>> org.hibernate.action.EntityInsertAction.execute(EntityInsert Action.java:79)
>>
>> at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:27 9)
>> at org.hibernate.engine.ActionQueue.executeActions(ActionQueue. java:263)
>> at org.hibernate.engine.ActionQueue.executeActions(ActionQueue. java:167)
>> at
>> org.hibernate.event.def.AbstractFlushingEventListener.perfor mExecutions(AbstractFlushingEventListener.java:321)
>>
>> at
>> org.hibernate.event.def.DefaultFlushEventListener.onFlush(De faultFlushEventListener.java:50)
>>
>> at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1028)
>> at
>> org.eclipse.emf.cdo.server.internal.hibernate.HibernateStore Accessor.write(HibernateStoreAccessor.java:613)
>>
>> at
>> org.eclipse.emf.cdo.internal.server.TransactionCommitContext .write(TransactionCommitContext.java:328)
>>
>> at
>> org.eclipse.emf.cdo.spi.server.InternalCommitContext$1.runLo op(InternalCommitContext.java:35)
>>
>> at
>> org.eclipse.emf.cdo.spi.server.InternalCommitContext$1.runLo op(InternalCommitContext.java: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:316)
>>
>>
>> at
>> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication.indicating(CommitTransactionIndication.ja va:168)
>>
>>
>> at
>> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication.indicating(CommitTransactionIndication.ja va:122)
>>
>>
>> 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:315)
>> 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:240)
>> at org.eclipse.net4j.signal.Signal.run(Signal.java:146)
>> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unkno wn Source)
>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
>> at java.lang.Thread.run(Unknown Source)
>>
>> I saw that CDO converts the geometry to a String when committing to
>> the server side.
>> It's just a supposition, but the problem seems to be somewhere in the
>> processing between CDO and Hibernate :
>> The String is not converted back to a Geometry
>> (com.vividsolutions.jts.geom.Geometry) object before it is handled by
>> hibernate (that is to say, by GeometryUserType)...
>> But I don't really know if it should...
>>
>> Any advice would be appreciated :)
>> Thanks a lot in advance !
>>
>> SWT
>
>
Re: [CDO][Teneo] Persistance of Custom EDataType [message #664018 is a reply to message #663712] Thu, 07 April 2011 08:18 Go to previous messageGo to next message
Martin Taal is currently offline Martin TaalFriend
Messages: 5468
Registered: July 2009
Senior Member
Hi SWT,
Your comments make sense.
I discussed this with Eike, CDO does not assume that the generated epackages are present on the server, i.e. that the
custom types are present on the server. So therefore the conversion to string.
However, each IStore is free to check and handle custom edatatypes more specifically if they custom classes are present
on the server (and fall back to default behavior if they are not available).
So this would be a good feature for the Hibernate store. Can you enter a bugzilla for this?

gr. Martiin

On 04/06/2011 11:26 AM, SWT wrote:
> Hi Martin,
>
> I can do that but this seems a bit problematic.
> The "GeometryUserType" class is not mine, it's provided by "hibernate spatial" (http://www.hibernatespatial.org/). It's
> a hibernate extension project. So the GeometryUserType may change along with new releases of hibernate spatial, but even
> with new releases of hibernate, etc.
>
> For this time, I can use the source code of hibernate spatial to make it work with CDO (using Strings) but for future
> versions, it's not really ok to have to maintain a "CDO compatible version" of hibernate spatial...
> Same issue may be raised for other "UserType" implementations provided for Hibernate : these implementations won't work
> with CDO...
>
> This is IMHO a general problem :
> There may be numerous hibernate extensions for various "custom types". Each "custom type" has a corresponding "UserType"
> implementation that manipulates the corresponding java type and not the String type. (See the UserType class javadoc :
> http://docs.jboss.org/hibernate/core/3.5/api/org/hibernate/u sertype/UserType.html)
>
> What you are suggesting is that for each of these custom types, a "CDO UserType" implementation should be written, that
> does the same thing the "standard UserType" (the one provided for "standard hibernate usage") does but with String
> objects instead...
>
>
> Stop me if I'm wrong :
> Manipulating String objects is required because CDORevisions' objects contain only serialized String values when
> committing a transaction from the client to the server.
> Once on the server side, the CDORevisions' objects must be stored in a database (via hibernate or not). But the String
> values are values serialized for transport from client to server. These are not values serialized for database storage.
>
> What I mean is that IMO, the steps of a commit should look like :
>
> CLIENT OBJECTS WITH "OBJECT" VALUES
> ===== Serialization for transport ("convertToString") ===>
> CLIENT OBJECTS WITH "STRING" VALUES
> [ Transport to server through CDORevision ]
> SERVER REVISION WITH "STRING" VALUES
> ===== Deserialization ("createFromString") ===>
> SERVER REVISION WITH "OBJECT" VALUES
> ===== Database storage ===>
> DATABASE UPDATED CONTENTS
>
> In these steps, the "Database storage" step takes care of converting objects to something that can be persisted. That is
> to say, this part uses the "UserType" implementations when need.
> But currently, in CDO, the "Deserialization" step does not exist (if I do not miss something). So "UserType"
> implementations get String values instead of object values.
>
> This is quite like saying that the "convertToString" method is used to serialize a value so that it can be stored in the
> database. To me, it's not true... It should be meant to serialize value for transport only. Am I wrong ?
>
> Anyway, I'll try implementing a GeometryUserType which handles String for the moment. But I'd really like to know if I'm
> right or wrong in this analysis...
> I hope I'm wrong and I missed something in CDO design. But if I'm right, I hope this can be addressed because it sounds
> like an important issue to me...
>
> SWT
>
> Le 05/04/2011 18:44, Martin Taal a écrit :
>> Hi SWT,
>> I guess that your GeometryUserType should be changed to handle strings
>> and not the Geometry object you assume currently. This string can be
>> converted back to the actual object on the client I guess.
>>
>> gr. Martin
>>
>> On 04/04/2011 07:01 PM, SWT wrote:
>>> Hi list,
>>>
>>> I'd like to store a custom EDataType in a database using CDO Hibernate
>>> Store.
>>> I started with the "hibernate store quickstart" which I managed to get
>>> working using a PostgreSQL/PostGIS database.
>>> Moreover, instead of the "PostgresqlDialect", I use a "PostgisDialect".
>>> PostGIS is a PostgreSQL extension for spatial data.
>>>
>>> Now, I'd like to add a new EAttribute to the EClass "Address", which
>>> corresponds to the geographic coordinates
>>> (latitude/longitude) of the address.
>>> In order to do this, I defined a new EDataType named "Geometry".
>>> It is mapped to the java type "com.vividsolutions.jts.geom.Geometry"
>>> (an abstract class which stores geographic data
>>> such as points, polygons, etc.)
>>> I also added to this EDataType, the following EAnnotation :
>>> Source = teneo.jpa
>>> Detail :
>>> Key = appinfo
>>> Value = @TypeDef(name="Geometry",
>>> typeClass="org.hibernatespatial.GeometryUserType")
>>>
>>> I modified the "QuickStartTest" class provided in the examples in
>>> order to set a value to the geometry attribute of the
>>> "address".
>>>
>>> When I run the test, I get the following exception on the server side :
>>> Hibernate: insert into "address" (resource_id, container_id, version,
>>> "name", "street", "city", "geometry", idcol)
>>> values (?, ?, ?, ?, ?, ?, ?, ?)
>>> [ERROR] java.lang.String cannot be cast to
>>> com.vividsolutions.jts.geom.Geometry
>>> java.lang.ClassCastException: java.lang.String cannot be cast to
>>> com.vividsolutions.jts.geom.Geometry
>>> at
>>> org.hibernatespatial.AbstractDBGeometryType.nullSafeSet(Abst ractDBGeometryType.java:152)
>>>
>>> at
>>> org.hibernatespatial.GeometryUserType.nullSafeSet(GeometryUs erType.java:186)
>>>
>>> at org.hibernate.type.CustomType.nullSafeSet(CustomType.java:16 9)
>>> at
>>> org.hibernate.persister.entity.AbstractEntityPersister.dehyd rate(AbstractEntityPersister.java:2015)
>>>
>>> at
>>> org.hibernate.persister.entity.AbstractEntityPersister.inser t(AbstractEntityPersister.java:2261)
>>>
>>> at
>>> org.hibernate.persister.entity.AbstractEntityPersister.inser t(AbstractEntityPersister.java:2678)
>>>
>>> at
>>> org.hibernate.action.EntityInsertAction.execute(EntityInsert Action.java:79)
>>>
>>> at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:27 9)
>>> at org.hibernate.engine.ActionQueue.executeActions(ActionQueue. java:263)
>>> at org.hibernate.engine.ActionQueue.executeActions(ActionQueue. java:167)
>>> at
>>> org.hibernate.event.def.AbstractFlushingEventListener.perfor mExecutions(AbstractFlushingEventListener.java:321)
>>>
>>> at
>>> org.hibernate.event.def.DefaultFlushEventListener.onFlush(De faultFlushEventListener.java:50)
>>>
>>> at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1028)
>>> at
>>> org.eclipse.emf.cdo.server.internal.hibernate.HibernateStore Accessor.write(HibernateStoreAccessor.java:613)
>>>
>>> at
>>> org.eclipse.emf.cdo.internal.server.TransactionCommitContext .write(TransactionCommitContext.java:328)
>>>
>>> at
>>> org.eclipse.emf.cdo.spi.server.InternalCommitContext$1.runLo op(InternalCommitContext.java:35)
>>>
>>> at
>>> org.eclipse.emf.cdo.spi.server.InternalCommitContext$1.runLo op(InternalCommitContext.java: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:316)
>>>
>>>
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication.indicating(CommitTransactionIndication.ja va:168)
>>>
>>>
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication.indicating(CommitTransactionIndication.ja va:122)
>>>
>>>
>>>
>>> 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:315)
>>> 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:240)
>>> at org.eclipse.net4j.signal.Signal.run(Signal.java:146)
>>> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unkno wn Source)
>>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
>>> at java.lang.Thread.run(Unknown Source)
>>>
>>> I saw that CDO converts the geometry to a String when committing to
>>> the server side.
>>> It's just a supposition, but the problem seems to be somewhere in the
>>> processing between CDO and Hibernate :
>>> The String is not converted back to a Geometry
>>> (com.vividsolutions.jts.geom.Geometry) object before it is handled by
>>> hibernate (that is to say, by GeometryUserType)...
>>> But I don't really know if it should...
>>>
>>> Any advice would be appreciated :)
>>> Thanks a lot in advance !
>>>
>>> SWT
>>
>>
>


--

With Regards, Martin Taal

Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Cell: +31 (0)6 288 48 943
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org
Re: [CDO][Teneo] Persistance of Custom EDataType [message #664107 is a reply to message #664018] Thu, 07 April 2011 13:24 Go to previous message
Eclipse UserFriend
Originally posted by: swt.magellium.fr

Hi again :)

Bugzilla created :
https://bugs.eclipse.org/bugs/show_bug.cgi?id=342147

As I'm never sure to be clear in my explanations, I detailled a lot, and
provided some files to reproduce the problem using a PostgreSQL DB with
the PostGIS extension installed, but this could also be done using any
spatial-enabled DB (Oracle, SQL server, MySQL, GeoDB).

And of course, this can also be reproduced without any spatial stuff,
using a home-made custom type (if you can provide the corresponding
org.hibernate.usertype.UserType implementation), as described in the
bugzilla...

SWT

Le 07/04/2011 10:18, Martin Taal a écrit :
> Hi SWT,
> Your comments make sense.
> I discussed this with Eike, CDO does not assume that the generated
> epackages are present on the server, i.e. that the custom types are
> present on the server. So therefore the conversion to string.
> However, each IStore is free to check and handle custom edatatypes more
> specifically if they custom classes are present on the server (and fall
> back to default behavior if they are not available).
> So this would be a good feature for the Hibernate store. Can you enter a
> bugzilla for this?
>
> gr. Martiin
>
> On 04/06/2011 11:26 AM, SWT wrote:
>> Hi Martin,
>>
>> I can do that but this seems a bit problematic.
>> The "GeometryUserType" class is not mine, it's provided by "hibernate
>> spatial" (http://www.hibernatespatial.org/). It's
>> a hibernate extension project. So the GeometryUserType may change
>> along with new releases of hibernate spatial, but even
>> with new releases of hibernate, etc.
>>
>> For this time, I can use the source code of hibernate spatial to make
>> it work with CDO (using Strings) but for future
>> versions, it's not really ok to have to maintain a "CDO compatible
>> version" of hibernate spatial...
>> Same issue may be raised for other "UserType" implementations provided
>> for Hibernate : these implementations won't work
>> with CDO...
>>
>> This is IMHO a general problem :
>> There may be numerous hibernate extensions for various "custom types".
>> Each "custom type" has a corresponding "UserType"
>> implementation that manipulates the corresponding java type and not
>> the String type. (See the UserType class javadoc :
>> http://docs.jboss.org/hibernate/core/3.5/api/org/hibernate/u sertype/UserType.html)
>>
>>
>> What you are suggesting is that for each of these custom types, a "CDO
>> UserType" implementation should be written, that
>> does the same thing the "standard UserType" (the one provided for
>> "standard hibernate usage") does but with String
>> objects instead...
>>
>>
>> Stop me if I'm wrong :
>> Manipulating String objects is required because CDORevisions' objects
>> contain only serialized String values when
>> committing a transaction from the client to the server.
>> Once on the server side, the CDORevisions' objects must be stored in a
>> database (via hibernate or not). But the String
>> values are values serialized for transport from client to server.
>> These are not values serialized for database storage.
>>
>> What I mean is that IMO, the steps of a commit should look like :
>>
>> CLIENT OBJECTS WITH "OBJECT" VALUES
>> ===== Serialization for transport ("convertToString") ===>
>> CLIENT OBJECTS WITH "STRING" VALUES
>> [ Transport to server through CDORevision ]
>> SERVER REVISION WITH "STRING" VALUES
>> ===== Deserialization ("createFromString") ===>
>> SERVER REVISION WITH "OBJECT" VALUES
>> ===== Database storage ===>
>> DATABASE UPDATED CONTENTS
>>
>> In these steps, the "Database storage" step takes care of converting
>> objects to something that can be persisted. That is
>> to say, this part uses the "UserType" implementations when need.
>> But currently, in CDO, the "Deserialization" step does not exist (if I
>> do not miss something). So "UserType"
>> implementations get String values instead of object values.
>>
>> This is quite like saying that the "convertToString" method is used to
>> serialize a value so that it can be stored in the
>> database. To me, it's not true... It should be meant to serialize
>> value for transport only. Am I wrong ?
>>
>> Anyway, I'll try implementing a GeometryUserType which handles String
>> for the moment. But I'd really like to know if I'm
>> right or wrong in this analysis...
>> I hope I'm wrong and I missed something in CDO design. But if I'm
>> right, I hope this can be addressed because it sounds
>> like an important issue to me...
>>
>> SWT
>>
>> Le 05/04/2011 18:44, Martin Taal a écrit :
>>> Hi SWT,
>>> I guess that your GeometryUserType should be changed to handle strings
>>> and not the Geometry object you assume currently. This string can be
>>> converted back to the actual object on the client I guess.
>>>
>>> gr. Martin
>>>
>>> On 04/04/2011 07:01 PM, SWT wrote:
>>>> Hi list,
>>>>
>>>> I'd like to store a custom EDataType in a database using CDO Hibernate
>>>> Store.
>>>> I started with the "hibernate store quickstart" which I managed to get
>>>> working using a PostgreSQL/PostGIS database.
>>>> Moreover, instead of the "PostgresqlDialect", I use a "PostgisDialect".
>>>> PostGIS is a PostgreSQL extension for spatial data.
>>>>
>>>> Now, I'd like to add a new EAttribute to the EClass "Address", which
>>>> corresponds to the geographic coordinates
>>>> (latitude/longitude) of the address.
>>>> In order to do this, I defined a new EDataType named "Geometry".
>>>> It is mapped to the java type "com.vividsolutions.jts.geom.Geometry"
>>>> (an abstract class which stores geographic data
>>>> such as points, polygons, etc.)
>>>> I also added to this EDataType, the following EAnnotation :
>>>> Source = teneo.jpa
>>>> Detail :
>>>> Key = appinfo
>>>> Value = @TypeDef(name="Geometry",
>>>> typeClass="org.hibernatespatial.GeometryUserType")
>>>>
>>>> I modified the "QuickStartTest" class provided in the examples in
>>>> order to set a value to the geometry attribute of the
>>>> "address".
>>>>
>>>> When I run the test, I get the following exception on the server side :
>>>> Hibernate: insert into "address" (resource_id, container_id, version,
>>>> "name", "street", "city", "geometry", idcol)
>>>> values (?, ?, ?, ?, ?, ?, ?, ?)
>>>> [ERROR] java.lang.String cannot be cast to
>>>> com.vividsolutions.jts.geom.Geometry
>>>> java.lang.ClassCastException: java.lang.String cannot be cast to
>>>> com.vividsolutions.jts.geom.Geometry
>>>> at
>>>> org.hibernatespatial.AbstractDBGeometryType.nullSafeSet(Abst ractDBGeometryType.java:152)
>>>>
>>>>
>>>> at
>>>> org.hibernatespatial.GeometryUserType.nullSafeSet(GeometryUs erType.java:186)
>>>>
>>>>
>>>> at org.hibernate.type.CustomType.nullSafeSet(CustomType.java:16 9)
>>>> at
>>>> org.hibernate.persister.entity.AbstractEntityPersister.dehyd rate(AbstractEntityPersister.java:2015)
>>>>
>>>>
>>>> at
>>>> org.hibernate.persister.entity.AbstractEntityPersister.inser t(AbstractEntityPersister.java:2261)
>>>>
>>>>
>>>> at
>>>> org.hibernate.persister.entity.AbstractEntityPersister.inser t(AbstractEntityPersister.java:2678)
>>>>
>>>>
>>>> at
>>>> org.hibernate.action.EntityInsertAction.execute(EntityInsert Action.java:79)
>>>>
>>>>
>>>> at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:27 9)
>>>> at
>>>> org.hibernate.engine.ActionQueue.executeActions(ActionQueue. java:263)
>>>> at
>>>> org.hibernate.engine.ActionQueue.executeActions(ActionQueue. java:167)
>>>> at
>>>> org.hibernate.event.def.AbstractFlushingEventListener.perfor mExecutions(AbstractFlushingEventListener.java:321)
>>>>
>>>>
>>>> at
>>>> org.hibernate.event.def.DefaultFlushEventListener.onFlush(De faultFlushEventListener.java:50)
>>>>
>>>>
>>>> at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1028)
>>>> at
>>>> org.eclipse.emf.cdo.server.internal.hibernate.HibernateStore Accessor.write(HibernateStoreAccessor.java:613)
>>>>
>>>>
>>>> at
>>>> org.eclipse.emf.cdo.internal.server.TransactionCommitContext .write(TransactionCommitContext.java:328)
>>>>
>>>>
>>>> at
>>>> org.eclipse.emf.cdo.spi.server.InternalCommitContext$1.runLo op(InternalCommitContext.java:35)
>>>>
>>>>
>>>> at
>>>> org.eclipse.emf.cdo.spi.server.InternalCommitContext$1.runLo op(InternalCommitContext.java: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:316)
>>>>
>>>>
>>>>
>>>>
>>>> at
>>>> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication.indicating(CommitTransactionIndication.ja va:168)
>>>>
>>>>
>>>>
>>>>
>>>> at
>>>> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication.indicating(CommitTransactionIndication.ja va:122)
>>>>
>>>>
>>>>
>>>>
>>>> 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:315)
>>>> 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:240)
>>>> at org.eclipse.net4j.signal.Signal.run(Signal.java:146)
>>>> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unkno wn
>>>> Source)
>>>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
>>>> at java.lang.Thread.run(Unknown Source)
>>>>
>>>> I saw that CDO converts the geometry to a String when committing to
>>>> the server side.
>>>> It's just a supposition, but the problem seems to be somewhere in the
>>>> processing between CDO and Hibernate :
>>>> The String is not converted back to a Geometry
>>>> (com.vividsolutions.jts.geom.Geometry) object before it is handled by
>>>> hibernate (that is to say, by GeometryUserType)...
>>>> But I don't really know if it should...
>>>>
>>>> Any advice would be appreciated :)
>>>> Thanks a lot in advance !
>>>>
>>>> SWT
>>>
>>>
>>
>
>
Previous Topic:[CDO] Database backup/restore on server side
Next Topic:[CDO] Locking in CDO 3 and 4
Goto Forum:
  


Current Time: Fri Mar 29 04:59:31 GMT 2024

Powered by FUDForum. Page generated in 0.04335 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top