Re: Prepared Statements - Mailing list pgsql-jdbc

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