Re: Avoiding explicit addDataType calls for PostGIS - Mailing list pgsql-jdbc
From | Oliver Jowett |
---|---|
Subject | Re: Avoiding explicit addDataType calls for PostGIS |
Date | |
Msg-id | 417588E7.7020205@opencloud.com Whole thread Raw |
In response to | Re: Avoiding explicit addDataType calls for PostGIS (Kris Jurka <books@ejurka.com>) |
Responses |
Re: Avoiding explicit addDataType calls for PostGIS
|
List | pgsql-jdbc |
Kris Jurka wrote: > 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, Yes, that's what I was trying to avoid. > but I don't like the idea of invading a global namespace. We should be OK so long as we don't get a conflict with some other postgresql-related java application (who else is going to use that name?) We could call it 'postgresql.jdbc-driver.properties' or something if you like. > 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. This is a bit of a can of worms.. The datasource implementations don't currently provide access to many of the useful properties the driver has. The ones it does support are handled via generating an appropriate URL to pass to getConnection(). This is going to get unwieldly very fast. I'd suggest using the Properties variant of getConnection() to pass extra options in. How should defaults interact with datasource settings? If you serialize a configured datasource and later deserialize it in an environment where the driver defaults are different, do you get the updated defaults for values you didn't set on the datasource, or do you get the defaults at the time the object was serialized? Should we distinguish "not set" from "set to X" for all properties? This plays more nicely with defaults ("not set" means "use default") but also means we can't easily use primitive types in the accessors (e.g. get/setPrepareThreshold would have to deal in something other than a bare 'int'). This also seems necessary for things like the ssl property in its current form. Should it be possible to reset a datasource property to "not set" after setting it to something else? If you call a getter on a datasource when the underlying value is defaulted (i.e. not explicitly set) should you get a result meaning "this value is at whatever the default is" or should the datasource look up the actual default that would be used if you created a connection right now and return that? For the datatype.* properties, how do we map them to datasource accessors? Having many separate properties is nice from the point of view of being able to incrementally add to the property via different defaults files, but it's nasty to map to a JavaBean-like accessors (and also makes Driver.getPropertyInfo() impossible to completely implement). Perhaps an array-based accessor, one element per datatype? Alternatively, collapse all the datatype stuff down to a single property and teach the property-munging code how to merge (rather than replace) multiple settings of that property together. (this second option is more like what JNDI property files do) phew. -O
pgsql-jdbc by date: