Dibyendu Majumdar wrote:
From: "Jeremy Boynes" <[EMAIL PROTECTED]>
The advantage of a unified model is that there is only one
implementation *within Derby.* Having multiple ones for one product
depending on the JVM and transport in use is just confusing.
I think another problem with a unified im
From: "Jeremy Boynes" <[EMAIL PROTECTED]>
> The advantage of a unified model is that there is only one
> implementation *within Derby.* Having multiple ones for one product
> depending on the JVM and transport in use is just confusing.
I think another problem with a unified implementation is tha
Dibyendu Majumdar wrote:
From: "Jeremy Boynes" <[EMAIL PROTECTED]>
But all implementations follow the JavaBean model so it is fairly easy
to write an application that can generically handle any vendor's
implementation.
Is that part of the spec, or just convention? Is it mandatory for a
DataSourc
Daniel John Debrunner wrote:
I wasn't talking about that DataSource, but a possible optimisation
where a Java Bean (as you call it, I was using 'DataSource (like)' :-)
:-)
could be pre-populated for the common connection requests, to avoid
having to create a new Java Bean object each time. With suc
From: "Jeremy Boynes" <[EMAIL PROTECTED]>
> But all implementations follow the JavaBean model so it is fairly easy
> to write an application that can generically handle any vendor's
> implementation.
Is that part of the spec, or just convention? Is it mandatory for a
DataSource implementation to
Dibyendu Majumdar wrote:
I think that building a unified DataSource API will actually not help
very much because the problem is that there is no standard interface for a
DataSource anyway.
However, there is a common configuration model, that of a JavaBean. This
is easy to map to a GUI for
Manager model.
I think that building a unified DataSource API will actually not help
very much because the problem is that there is no standard interface for a
DataSource anyway. Even if Derby had a unified API, you still have to deal
with
differences in other DBMS implementations. So, in the
Jeremy Boynes wrote:
> Daniel John Debrunner wrote:
>
>>> I don't see where state management comes in.
>>
>>
>>
>> With your proposal when a JDBC URL request comes a DataSource (like)
>> object is required to obtain the connection, either:
>>
>> - the object is created and filled in on the fly -
Dibyendu Majumdar wrote:
From: "Jeremy Boynes" <[EMAIL PROTECTED]>
With the JDBC 2.0 extension and 3.0, DataSource became available as the
preferred mechanism. Ideally this would be via JNDI lookup (although
there is no standard provider and/or location for the binding in J2SE),
but as an altern
Daniel John Debrunner wrote:
I don't see where state management comes in.
With your proposal when a JDBC URL request comes a DataSource (like)
object is required to obtain the connection, either:
- the object is created and filled in on the fly - possible extra
overhead, though maybe the existing
From: "Jeremy Boynes" <[EMAIL PROTECTED]>
> With the JDBC 2.0 extension and 3.0, DataSource became available as the
> preferred mechanism. Ideally this would be via JNDI lookup (although
> there is no standard provider and/or location for the binding in J2SE),
> but as an alternative configurati
Jeremy Boynes wrote:
>>> At the bottom level you need some generic interface that hands a
>>> connection back, today it is based upon the stateless
>>> DriverManager/Driver model, with the connection being completely defined
>>> by a JDBC URL and a set of properties.
>>>
>>> Not sure of the advan
Jeremy Boynes wrote:
Lance J. Andersen wrote:
The reality is that there are way too many applications which utilize
java.sql.Driver implementations to depecrate this functionality.
We are in JDBC 4 reducing the boiler plate code by having
DriverManager.getConnection() utilize the Server Provid
Lance J. Andersen wrote:
The reality is that there are way too many applications which utilize
java.sql.Driver implementations to depecrate this functionality.
We are in JDBC 4 reducing the boiler plate code by having
DriverManager.getConnection() utilize the Server Provider Mechanism in
J2SE
The reality is that there are way too many applications which utilize
java.sql.Driver implementations to depecrate this functionality.
We are in JDBC 4 reducing the boiler plate code by having
DriverManager.getConnection() utilize the Server Provider Mechanism in
J2SE to load the driver, remo
Jeremy Boynes wrote:
>
> 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.
Should we be encouraging J2SE/J2EE applications to
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 appli
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
>
This sounds reasonable to me...
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 t
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
20 matches
Mail list logo
