Jeremy Boynes wrote: > Daniel John Debrunner wrote: > >> >> To my mind, with a DataSource connectionAttributes should only be used >> for cases where the attribute can not be set as a property, thus their >> value should be ignored or overridden by any explict setting. >> > > +1 > > I would actually go for dropping the connectionAttributes property > entirely and make sure that everything can be set using datasource > properties.
Some of the history behind this is related to the flexible authentication schemes Derby allows. org.apache.derby.authentication.UserAuthenticator allows any key-value pairs (rather than just user & password) from the Properties object or JDBC URL attributes to be used to authenticate the user. This flexibility was carried forward into the DataSource world through connectionAttributes. Ie. it provides the ability to supply any attributes into the connection request. However, the DataSource api really forces databases into a user & password authentication scheme, since those are the only per-connection attributes possible (unless one moves to a DataSource per connection model). So, I agree Derby supported attributes should be exposed as Derby DataSource properties, but removing connectionAttributes altogether I'm not sure about. As a first step, in my javadoc cleanup I'll add some comments to connectionAttribute indicating where possible DataSource properties should be used, and conflicting attributes might lead to unexpected behaviour. Dan.
