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