Re: Avoiding explicit addDataType calls for PostGIS

Markus Schaber wrote:

> Both PostGIS and JTS (using the JtsGeometry Wrapper Class attached to
> this mail) support direct reading of their geometry classes via
> ResultSet.getObject(int) method.

> But it is annoying that one has to explicitly call the addDataType()
> method on every connection at startup. First, this puts PostGIS/JTS
> specific code in places that should be driver independend. Second, it
> does not play well with connection pooling (jboss etc.) as one always
> has to re-add those datatypes on any connection you get.

If your objective is to produce a driver that automatically supports the
extra datatypes, how about a provider-properties-file approach?

i.e. when creating a new connection, the postgresql driver looks for all
resources called postgresql.properties (or whatever) via
ClassLoader.getResources() and reads each in turn. They are interpreted
as properties files, and the resulting properties drive datatype
registration. It could also perhaps be used for other driver
configuration, things like setting the default prepareThreshold etc. in
the absence of URL instructions to the contrary.

Then we can distribute a stock JDBC driver that has
postgresql.properties looking something like:

   postgresql.datatype.box=org.postgresql.geometric.PGbox
   postgresql.datatype.circle=org.postgresql.geometric.PGcircle
   ...

Perhaps we want to interpret postgresql.<a>=<b> identically to a URL
parameter of <a>=<b> to make it more general? This is then essentially
your list-of-datatypes-in-URL approach, with a bit of extra flexibility
so you can easily specify new defaults.

PostGIS/JTS can package the basic JDBC driver together with the
appropriate extra datatype classes and a new postgresql.properties. All
users of that driver then get the new datatypes automatically registered.

You still have the problem that the driver must be able to load the
datatype classes from the driver's classloader, but if you're
repackaging the driver to include extra types, I think that's acceptable
(if you can add a postgresql.properties, you can presumably add the
extra classes too..)

How does that fit with what you need?

(for another example of this approach, see the JNDI resource file docs
at
http://java.sun.com/j2se/1.4.2/docs/api/javax/naming/Context.html#RESOURCEFILES)

-O