Re: Avoiding explicit addDataType calls for PostGIS

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