db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@debrunners.com>
Subject Re: Unified DataSource API
Date Mon, 09 May 2005 18:04:11 GMT
Jeremy Boynes wrote:
> There has been a fair amount of discussion recently about keeping
> compatibility between the embedded and client APIs for creating and
> configuring DataSources.
> We currently have three DataSource implementations:
> * EmbeddedDataSource - used by the SE embedded impl
> * EmbeddedSimpleDataSource - used by the JSR169/ME impl
> * ClientDataSource - used by the SE client code
> not including the variations for Pooled and XA connnections, or ME
> support for the client.
> IIRC the only one present in 10.0 was the EmbeddedDataSource so before
> we finalize 10.1 I think we should reexamine whether this is the way to go.
> As an alternative I would suggest as single unified DataSource that
> works in conjunction with a connection-factory to create connections and
> a reference-factory to create References for binding into JNDI.
> This would give us one public implementation of DataSource, simplifying
> the API for users and improving compatibility across environments. For
> example, the same application code could use either an embedded database
> or a client connection automatically based on the property values supplied.

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

A concrete proposal would be great, so we can see what is being made
simpler, and how much simpler.


View raw message