db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Satheesh Bandaram <banda...@gmail.com>
Subject Re: [jira] Commented: (DERBY-458) Make it clear the difference between EmbedConnection and Networked Connection
Date Tue, 23 Aug 2005 17:19:35 GMT
Some of the big differences you see is because of not fully completing
the Derby Client development... like the missing SQLStates or the
message bundle support. These were known issues when Derby client was
released, but I thought it is better to get some working functionality
out there than make it perfect before releasing it.

Kathey also brought up another possible code sharing proposal...
Sharing of protocol managing code between network client and server.
Like she said, it seems we still don't have a good working model for
sharing code that balances compatibility of future and past versions
in a good way yet.

Satheesh

On 8/22/05, David Van Couvering <David.Vancouvering@sun.com> wrote:
> 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...
> 
> Thanks,
> 
> David
> 
> 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.
> >
> >Dan.
> >
> >
> >
> >
> 
> 
>

Mime
View raw message