Re: Prepared Statements

>
>
>Um, so you don't want to depend on the JDBC postgresql driver at all, but
>don't mind having postgresql-specific behaviour elsewhere so long
>as you can do it purely through the JDBC interface? That seems a bit
>inconsistent.
>
>
I don't see anything "inconsistent" about it.
I am just choosing the lesser of two evils.
At least, I don't need to know what database I am going to be working
with when I compile the code.

>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...

Dima

>
>What I was suggesting was a scheme like:
>
> interface JDBCExtensions {
> void initStatement(PreparedStatement stmt);
> void setInClause(PreparedStatement stmt, int index, int[] values);
> }
>
> class PostgresqlJDBCExceptions implements JDBCExtensions {
> public void initStatement(PreparedStatement stmt) {
> ((org.postgresql.PGStatement)stmt).setUseServerPrepare(true);
> }
>
> public void setInClause(PreparedStatement stmt, int index, int[] values) {
> stmt.setArray(index, new org.postgresql.jdbc2.WrappedArray(values, Types.INTEGER));
> }
> }
>
> class FooJDBCExceptions implements JDBCExtensions {
> // implementation for FooDB
> }
>
> // ...
>
> Class datasourceClass = Class.forName(configuredDatasourceClass);
> Class extensionsClass = Class.forName(configuredExtensionsClass);
> JDBCExtensions extensions = extensionsClass.newInstance();
>
> // ...
>
> PreparedStatement stmt = connection.prepareStatement(...);
> extensions.initStatement(stmt);
> extensions.setInClause(stmt, 4, new int[] { 1,2,3,4 });
>
>Then conditionalize compilation of implementations of JDBCExceptions on the
>presence of the appropriate driver. When built, you get extension support
>for all the drivers present on the build system. When running from a built
>jar, only the configured extension class is loaded (and presumably the
>end-user has the corresponding JDBC driver available, or they can't talk to
>the DB anyway!)
>
>What prevents you from taking this approach?
>
>-O
>
>