Re: Avoiding explicit addDataType calls for PostGIS
От | Markus Schaber |
---|---|
Тема | Re: Avoiding explicit addDataType calls for PostGIS |
Дата | |
Msg-id | 20041019141015.6be89fa3@kingfisher.intern.logi-track.com обсуждение исходный текст |
Ответ на | Re: Avoiding explicit addDataType calls for PostGIS (Kris Jurka <books@ejurka.com>) |
Список | pgsql-jdbc |
Hi, Kris & Oliver, On Tue, 19 Oct 2004 01:57:47 -0500 (EST) Kris Jurka <books@ejurka.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@logi-track.com | www.logi-track.com
Вложения
В списке pgsql-jdbc по дате отправления: