Re: Avoiding explicit addDataType calls for PostGIS - Mailing list pgsql-jdbc

Hi, Oliver,

On Thu, 07 Oct 2004 10:11:22 +1300
Oliver Jowett <oliver@opencloud.com> wrote:

> 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.

That is a nice idea that allows to control default configuration without
recompiling, and without explicit code in the app. It bites me that I
missed that idea...

The major advantage would be that, by simply adding the postgis.jar to
the class path, the driver would automagically know the appropriate data
types - no further config needed.

But I wonder how you would handle the case when you have two connections
to GIS databases, where you want the first one to map PostGIS geometry
to JTS Java Objects, while the second one should produce PostGIS JDBC
objects. This example is not as artificial as it sounds, we currently
have two independent applications running in the same app server. You
will need a connection (rsp. datasource config) specific way to decide
which additional datatypes to add.

> 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.

Interpreting both URL parameters and properties would solve the conflict
problem I mentioned above, as long as one does not rely on the "default"
one because the property file read order may be non-deterministic.

> 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.

It is not necessary to mangle the original postgresql.properties. They
simply have to put a postgresql.properties in the appropriate path
(package) in their own jar. The driver then can use getResources() to
get an enumeration of all org/postgres/postgresql.properties that are
anywhere in the CLASSPATH, and loop over them to read all additional
datatypes. Plug&Play as it was intended.

I'm currently not shure, however, whether it's possible to create a
deterministic ordering for the ressource enumeration.

> 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..)

I also think that this is a minor problem, as one always can use
addDataType() or a Driver wrapper class when needing classes from
specific class loaders.

> How does that fit with what you need?

I think it's a very nice idea, and will definitely make the life easier
for most people.

And, combined with the URL param = properties param approach, we can
even handle the above mentioned collision very fine.

Maybe we cannot provide all of the flexibility my footnote [2] in the
original posting said ("they also allow for other modifications to the
connection, e. G. to add prepared statements that are used by most
clients etc."), but it would provide the most elegant solution for my
original problem.


Thanks,
Markus Schaber
--
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