Re: datatype conversion thoughts - Mailing list pgsql-jdbc

Hi, Kris,

[Sorry for the duplicate message - I really should learn how to
configure my mailer, this message should have gone to the list directly.]

On Sat, 9 Oct 2004 02:19:37 -0500 (EST)
Kris Jurka <books@ejurka.com> wrote:

> One way of doing this would be provide a PGDataType abstract class
> that provided every getXXX method (getInt, getFloat, getBoolean, ...)
> which had a default implementation of saying "Invalid conversion...".
> Then for each datatype an implementation would be provided that could
> parse the underlying data and perform whatever conversions that are
> applicable on it.  This would work the same way on the reverse side
> (converting from java -> pg) as the implementation would provide a
> method for converting to the format pg is expecting.

That sounds great.

I assume the PGDataType subclasses would be used like factories.

When carefully crafted, this could even allow the PGDataType factory to
directly instantiate classes like org.postgis.Point or JTS geometry
classes to be returned by getObject(), without need to subclassing
PGObject. This would allow to unify custom and built-in data types,
including ability to override built-ins.

<shameless rant - consume with a grain of salt>

One of the most annoying aspects of the current PGObject approach is
that the current architecture instantiates the custom data types and
then passes the data to them via setValue. The jdbc driver only knows
its a geometry object, but not the appropriate subclass (Point, Polygon
etc.) which is encoded in the data itsself. So currently, PGGeometry and
other PGObject subclasses are factories that create and remember the
appropriate geometry subclass in setValue. Then the user calls
getObject() to get the PGGeometry wrapper, and then the getGeometry()
method to get the actual geometry class.

Another drawback is lacking support for binary transfer, the getValue()
and setValue() only work with slow and inefficient String
representations. This even lead to the development of wkb4j that uses a
hex encoded binary representation to speed-up reading, see
http://wkb4j.sourceforge.net/

</rant>

This would need a "backwards-mapping" from setObject classes to the
PGDataType factory for writing data. This could be accomplished by
combining a Map where the PGDataTypes register the classes they know to
handle, and a probing scheme with auto-caching for the case someone puts
subclasses into setObject.

Your concept would render my "Register arbitrary types framework" demand
obsolete (which I posted here on March 10, and then abandoned
temporarily).

BTW, this would even allow someone to transparently emulate other
manufacturers drivers by writing e. G. a PGDataType implementation that
handles oracle spatial GIS objects. This could ease the transition to
PostgreSQL (provided the user has the appropriate license for the oracle
java classes that would still be needed).


So, I'd give a +10 on this suggestion.

Or am I completely misleaded?

Markus
--
markus schaber | dipl. informatiker
logi-track ag | rennweg 14-16 | ch 8001 zürich
phone +41-43-888 62 52 | fax +41-43-888 62 53
mailto:schabios@logi-track.com | www.logi-track.com