You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cayenne.apache.org by Tore Halset <ha...@pvv.ntnu.no> on 2006/05/03 13:50:39 UTC

extended type and subclasses

Hello.

I am using an ExtendedType to map a JTS Geometry to a CLOB as done here:

http://objectstyle.org/confluence/display/CAY/Mapping+JTS+Geometries

This has been working ok, but I have only used it for reading. Trying  
to use the same ExtendedType for writing got me into an annoying  
problem. On writing I typically set a Polygon or MultiPolygon on the  
CayenneDataObject. P and MP are both subclasses of the mapped  
Geometry, but are not mapped correctly as the map only contains class  
names.

I have updated the example in the wiki to reflect this "problem".

Perhaps ExtendedType should map a Class (and handle subclasses)  
instead of a String holding a class name? Just wanted to discuss it  
here before creating a feature request for it.

Regards,
  - Tore.

Re: extended type and subclasses

Posted by Andrus Adamchik <an...@objectstyle.org>.
On May 3, 2006, at 7:50 AM, Tore Halset wrote:

> Hello.
>
> I am using an ExtendedType to map a JTS Geometry to a CLOB as done  
> here:
>
> http://objectstyle.org/confluence/display/CAY/Mapping+JTS+Geometries
>
> This has been working ok, but I have only used it for reading.  
> Trying to use the same ExtendedType for writing got me into an  
> annoying problem. On writing I typically set a Polygon or  
> MultiPolygon on the CayenneDataObject. P and MP are both subclasses  
> of the mapped Geometry, but are not mapped correctly as the map  
> only contains class names.
>
> I have updated the example in the wiki to reflect this "problem".
>
> Perhaps ExtendedType should map a Class (and handle subclasses)  
> instead of a String holding a class name? Just wanted to discuss it  
> here before creating a feature request for it.
>
> Regards,
>  - Tore.

Yeah, let's open a feature request for it. As for using Class instead  
of String class name as map keys - this can cause troubles with  
nested ClassLoaders. I guess instead we may reimplement  
'ExtendedTypeMap.getRegisteredType(Class)' to scan the class  
hierarchy up to, but not including, java.lang.Object before falling  
back to a default type.

Andrus