Subject | Re: [IB-Java] Re: JDBC Development |
---|---|
Author | Jim Starkey |
Post date | 2001-04-27T14:33:23Z |
At 08:05 AM 4/27/01 -0000, alberola@... wrote:
shouldn't be required to expose Firebird functionality
inaccessable through published JDBC since any Firebird
implementation class may have additional public methods
accessible with no more than an explicit cast. Exposing
functionality while keeping within the JDBC model is
a very good thing.
On the other hand, while you are implementing the gds interface
you will probably run into many instances where you have a
choice between close adherence to the gds32 interface and
general Java practice, and a judgement call will be required
(example -- return status or signalling errors). Since the
primary client (and if done well, the only client) is the
JDBC driver itself, close fidelity to the gds interface is
probably a good idea. But it will be your call.
Jim Starkey
>While there may be merit in a separable gds interface, it
> But this module won't be only a jdbc driver, it will be a
> complete suite of client APIs writen in Java. You will be
> able to write a Java application using GDS avoiding the
> use of JDBC in some contexts where you need functionality
> not found in a standard JDBC driver.
>
shouldn't be required to expose Firebird functionality
inaccessable through published JDBC since any Firebird
implementation class may have additional public methods
accessible with no more than an explicit cast. Exposing
functionality while keeping within the JDBC model is
a very good thing.
On the other hand, while you are implementing the gds interface
you will probably run into many instances where you have a
choice between close adherence to the gds32 interface and
general Java practice, and a judgement call will be required
(example -- return status or signalling errors). Since the
primary client (and if done well, the only client) is the
JDBC driver itself, close fidelity to the gds interface is
probably a good idea. But it will be your call.
Jim Starkey