db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Van Couvering <David.Vancouver...@Sun.COM>
Subject Re: [jira] Commented: (DERBY-458) Make it clear the difference between EmbedConnection and Networked Connection
Date Mon, 22 Aug 2005 22:05:36 GMT
Hm.  Logically I see your point, but I'm not sure I'm convinced.   If I 
were to build a new JDBC implementation and I had an existing one in 
place, I would like to inherit as much as possible from the existing 
implementation and diverge only where there is a difference, rather than 
start from scratch, which is basically where things stand now. 

In our case, the difference between the two implementation should 
/solely/ be the fact that the interaction with the next layer of Derby - 
I guess that would be the SQL layer - is local or over the network.  
Everything else should be identical (xcept perhaps in cases where you 
would get a very chatty network interaction, and some communication 
efficiencies can be obtained).

Right now we are discovering major differences, and we could pick at 
them one by one, but I do wonder if there is a more efficient way and 
ultimately more maintainable way to accomplish this...



Daniel John Debrunner wrote:

>David Van Couvering wrote:
>>Is it worth considering finding some way for the embedded and client
>>drivers to share some code, so that the only real difference is that the
>>network one is sending its commands over the wire?
>Possibly, but then you need common JDBC code that writes to a unified
>internal api (say derby-db-api), and then there are two implementations
>of derby-db-api, embedded and network.
>Thus you have to define a derby-db-api that supports all the
>functionality of JDBC.
>The current approach is that derby-db-api is JDBC, and the two
>implementations are the embedded  and client drivers.
>Maybe an extra level of indirection would save some code, but at the end
>of the day you still need two implementations of something, one for
>embedded and one for client.
>I just don't see this approach would be of much benefit.

View raw message