Daniel John Debrunner wrote:
Early implementation is one thing, but you want to get the public
interfaces right, or at least easily extensible, from the start so you
don't end up regretting something forever.
True, but in this case the public api is defined by class name(s) (that
implements DataSource) and a set of JeavBean properties, and what those
properties mean and how they interact with each other.
Thus we should not have a Java code strawman but instead a table of
properties, like table 9.1 in section 9.4 in JDBC 3.0 spec.
Though in the unified case the table would need additional columns to
indicate what they mean in each mode, emebedded, client etc.
I think that would be the best way to look at this, see how many
properties are common to each mode, how many could confuse users, e.g.
portNumber for embeddded (especially when running embedded with an
embedded network server). How complicated any rules are. etc.
Property overload for the user is what I'm concerned about.
I JavaDoc'ed the properties in the code including a description of how
they interact (to my knowledge at least). It seems fairly logical to me now.
I made the ConnectionFactory impl pluggable by the user with a default
impl that chooses embedded or client based on whether serverName is set
or not. I think the only redundant property is portNumber.
It does not yet support the client tracing options - I held off on that
because if we are going to unify we should support it in both client and
embedded modes and I don't think embedded has that (or if it does it is
set up differently).
Similarly with things like message text, database password, encryption,
result set holdability and so forth - they should work the same
regardless of whether the server in embedded or remote.
I still need to do the unified Driver impl - ran out of time this
weekend but may be able to get to it tomorrow (I have all day in a tin can).
I also ran into what appear a couple of quirks in the client but will
move those to a separate thread.
--
Jeremy
