db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <jboy...@apache.org>
Subject Re: Unified DataSource API
Date Tue, 10 May 2005 17:00:52 GMT
Daniel John Debrunner wrote:
> It's an interesting idea but the details may make it not possible, for
> example References don't exist in J2ME.
> Also since in the most case applications do not use Derby's or any
> DataSource implementation classes directly, I don't see how such a
> change would affect application code.
> I'm not convinced that the api will end up being simpler, yes there
> would only be one class name for the Derby data source implementation,
> but now there will be more properties and properties that do not apply
> to certain connection types. E.g. the single data source would need to
> have the port and server properties, but these are not relevant in an
> embedded mode, so is the api simpler because of that?
> The code and api will also have to define and implement rules about how
> those properties behave, e.g. if conflicting properties are set, what
> happens.
> A concrete proposal would be great, so we can see what is being made
> simpler, and how much simpler.

Strawman committed into a branch - not all possible properties are 
included but I figure that's just a matter of detail.

The main changes are:
* DerbyDataSource is the implementation expected to be used by end
   user applications (both J2SE and J2ME). This implements the basic
   DataSource API returning a single physical connection.

* ReferenceableDataSource is now a subclass rather than a base class.
   The reasoning is that it would only be used to bind data sources
   into a JNDI server that did not support Java Objects; this is a
   fairly specialized usecase. The only reason this is separate is
   because J2ME CDC/FP 1.0 does not support javax.naming.

* The intention is to use the same API for both client and server
   connections. The ConnectionFactory would create the appropriate
   Connection implementation depending on the properties in the
   DataSource. For example, if the networkProtocol is specified as
   "drda" and/or the serverName is non-null then a client connection
   would be created; if the protocol is "embedded" and/or serverName
   is null then we would create an embedded server. This makes the
   application code unaware of the physical location of the database.
   Yes, more concrete definition is needed for the semantics here.

* The Driver implementation now uses the DataSource implementation
   (without using the actual interface so we can continue to support
   JDBC 2.0 core) rather than the other way around. This seemed like
   a natural refactoring given the approach adopted by JSR169.


View raw message