On Mon, Jul 21, 2003 at 10:24:15AM -0400, Dmitry Tkach wrote:
> >Note that using setObject() to set IN clauses is no less
> >postgresql-specific
> >than using setArray() would be .. I know of at least one DB where you
> >really
> >can only set data values in a prepared statement as the prepared SQL is
> >compiled down to a form of bytecode for DB-side execution, there *is* no
> >textual substitution that goes on.
> >
> Right. I do need a scheme like what you suggest below to set up
> database-specific logic.
> The difference is - I do not need all the possible jdbc drivers to be
> installed just to compile my application.
> And I do not need to know which driver a particular customer is using to
> send him my application.
> And I don't need to force my customers to have to request a new app from
> me if they decide to switch to another database.
>
> With your suggestion, the only way I can have the above is to pack all
> the possible jdbc drivers into every build of the app...
Pack the support code for all drivers in, yes. The drivers themselves you
don't need to provide, as the support classes don't get loaded unless the
particular driver it supports is present.
There's no reason you can't have a "generic" extension implementation that
works on a plain JDBC driver -- you just don't get the benefit of the
extensions. Default to that for drivers you don't recognize at runtime.
If your app doesn't work without a real implementation of the extensions,
then you're not going to be able to just plug in a new JDBC driver and have
it work *regardless of how you get at those extensions* -- you have an
application that requires more JDBC provides, end of story. If you're in
this situation but want to allow your customers to run on arbitary DBs
without your intervention -- document your Extensions interface and release
it to your customers; they can build their own implementation for whatever
DB they like.
-O
