Re: Avoiding explicit addDataType calls for PostGIS

Hi, Kris & Oliver,

On Tue, 19 Oct 2004 01:57:47 -0500 (EST)
Kris Jurka <books(at)ejurka(dot)com> wrote:

> > > That is a nice idea that allows to control default configuration without
> > > recompiling, and without explicit code in the app.
> >
> > Here is a first cut at implementing this.
>
> This generally looks good, but I was hoping Markus would do some of the
> serious testing to see if it meets the needs of his real world app.

Sorry, I was a little busy the last days, but I tested the code, and it
worked fine. As we have the PostGIS and JTS jars in the jboss /lib
directory (just aside the pgjdbc driver), all application classloaders
are fine to load them. It allows us to use the JBoss connection pooling
without any weird hacks.

> Particularly the question about the order the property files are found and
> processed in. Additionally the claim that two applications running on the
> same JVM want to use two different mappings, I'm not sure that's possible.

It works, although you cannot always determine the default mapping as
soon as several extensions provide mappings for the same postgres type.
However, most users will not use both extensions at the same time.

But as the Properties Map and the URL parameters override the mappings
given there, it is possible on a per connection base to determine which
type of mapping you want (and even to override the default mappings). We
currently do this in the jboss pooling config files, just using
different datasource names for different mappings.

I just created a small test app (see attachment) that demonstrates this,
it produces the following output:

--- snip ---
Loading: PostgreSQL 8.0develschabi JDBC3 with SSL (build 306)
Testing: jdbc:postgresql://127.0.0.1:5432/logigis
Got: org.postgis.PGgeometry = POINT (42.0 23.0)

Testing: jdbc:postgresql://127.0.0.1:5432/logigis?datatype.geometry=org.postgis.PGgeometry
Got: org.postgis.PGgeometry = POINT (42.0 23.0)

Testing: jdbc:postgresql://127.0.0.1:5432/logigis?datatype.geometry=com.logitrack.gis.util.JtsGeometry
Got: com.logitrack.gis.util.JtsGeometry = POINT (42 23)
--- snap ---

The first test (without any explicit type) correctly indicates that I
have a postgresql.properties file defining the PostGIS class . When I
remove the file, test 2 and 3 are identical, but the first test spits
out the following text (as expected):

--- snip ---
Testing: jdbc:postgresql://127.0.0.1:5432/logigis
Got: org.postgresql.util.PGobject = SRID=-1;POINT(42 23)
--- snap ---

> Some simpler questions I had are:
>
> 1) Is the name postgresql.properties with no package name a good idea? It
> doesn't seem ideal for an application to have to create an org/postgresql
> directory just to hold a properties file, but I don't like the idea of
> invading a global namespace.

I agree, moving the file to org/postgresql/ would be a good idea. As my
mail from 7 Oct 2004 10:46:03 shows, this was my original interpretation
of Olivers proposal. Note that, typically, not the app will deliver the
property files, but the extension writers like PostGIS and/or JTS.

> 2) I notice you've set the default prepareThreshold to five as we agreed
> to a while ago, but I haven't gotten around to doing. The reason I
> haven't done it yet is because I was concerned about how to do this (and
> keep it in sync) for the DataSource implementations. With this patch it
> is impossible to set the prepareThreshold back to zero from the
> DataSource. It would be a simple fix to change the DataSource code to
> make this work, but since we're discussing the general ability to set
> defaults I thought I'd bring it up.

I think it is possible, using URL parameters or Properties in the
Datasource definition.

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(at)logi-track(dot)com | www.logi-track.com