Re: Avoiding explicit addDataType calls for PostGIS
От | Kris Jurka |
---|---|
Тема | Re: Avoiding explicit addDataType calls for PostGIS |
Дата | |
Msg-id | Pine.BSO.4.56.0410190144280.28027@leary.csoft.net обсуждение исходный текст |
Ответ на | Re: Avoiding explicit addDataType calls for PostGIS (Oliver Jowett <oliver@opencloud.com>) |
Ответы |
Re: Avoiding explicit addDataType calls for PostGIS
Re: Avoiding explicit addDataType calls for PostGIS |
Список | pgsql-jdbc |
On Tue, 12 Oct 2004, Oliver Jowett 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. 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. 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. 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. Kris Jurka
В списке pgsql-jdbc по дате отправления: