Re: [Springframework-developer] SqlTypeValue and SqlLobValue

[Tom T. <tom...@pr...>]

Hello Juergen,

Thanks for the changes!

However, a NativeJdbcExtractor _was_ specified on the JdbcTemplate, so I
did some debugging.

I'm using Commons DBCP (1.1) with CommonsDbcpNativeJdbcExtractor, and
its isNativeConnectionNecessaryForNativePreparedStatements() method is
inherited from NativeJdbcExtractorAdapter and always returns false.

Therefore, in the execute(PreparedStatementCreator psc,
PreparedStatementCallback action) method in JdbcTemplate, the conToUse
passed to psc.createPreparedStatement() at line 323 is the wrapped
connection, while it should be the native one for things to work the way
they are implemented right now.

I'm extending MappingSqlQuery, and my execute method looks like this:

public void execute(String[] codes) {
    execute(new Object[]{new AbstractSqlTypeValue() {
        protected Object createTypeValue(Connection con) throws
        SQLException {
            System.out.println("nativeJdbcExtractor =3D " +
            getJdbcTemplate().getNativeJdbcExtractor());
            System.out.println("con =3D " + con);
            try {
                throw new RuntimeException();
            } catch (RuntimeException ex) {
                ex.printStackTrace();
            }
            return null;
        }
    }});
}

Relevant output:

nativeJdbcExtractor =3D
org.springframework.jdbc.support.nativejdbc.CommonsDbcpNativeJdbcExtractor@=
396c7
con =3D org.apache.commons.dbcp.PoolableConnection@19fe5e6
java.lang.RuntimeException
        at
        discharge.TestCustomType$1.createTypeValue(TestCustomType.java:39)
        at
        org.springframework.jdbc.core.support.AbstractSqlTypeValue.setTypeV=
alue(AbstractSqlTypeValue.java:57)
        at
        org.springframework.jdbc.core.StatementCreatorUtils.setParameterVal=
ue(StatementCreatorUtils.java:97)
        at
        org.springframework.jdbc.core.StatementCreatorUtils.setParameterVal=
ue(StatementCreatorUtils.java:61)
        at
        org.springframework.jdbc.core.PreparedStatementCreatorFactory$Prepa=
redStatementCreatorImpl.setValues(PreparedStatementCreatorFactory.java:179)
        at
        org.springframework.jdbc.core.PreparedStatementCreatorFactory$Prepa=
redStatementCreatorImpl.createPreparedStatement(PreparedStatementCreatorFac=
tory.java:169)
        at
        org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.jav=
a:323)
        at
        org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:=
369)
        at
        org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:=
397)
        at
        org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:=
418)
        at
        org.springframework.jdbc.object.SqlQuery.execute(SqlQuery.java:111)
        at
        org.springframework.jdbc.object.SqlQuery.execute(SqlQuery.java:121)
        at discharge.TestCustomType.execute(TestCustomType.java:34)

I'm not sure how to fix this ;-)

In fact, I think the call to setValues() at line 169 in the
createPreparedStatement() method in PreparedStatementCreatorImpl in
PreparedStatementCreatorFactory [ahem], just shouldn't be there, and
should be done in doInPreparedStatement() in PreparedStatementCallback
instead (e.g. at line 374 in JdbcTemplate).

Hopefully you have a better idea though ;-)

Kind regards,
Tom.

P.S. This is against cvs version of about 10 hours ago.

On Mon, 28 Jun 2004 18:48:37 +0200, "j=FCrgen h=F6ller [werk3AT]"
<jue...@we...> said:
> Good points! I've just added the "typeName" parameter to setTypeValue and
> createTypeValue.
>=20=20
> Indeed, JdbcTemplate will normally work with the wrapped JDBC objects
> from the pool. However, you can specify a "nativeJdbcExtractor" on the
> JdbcTemplate instance: This will cause automatic unwrapping of all JDBC
> objects passed to callbacks. So if you specify that, you'll also get the
> native Connection respectively native PreparedStatement in your
> SqlTypeValue implementations.
>=20=20
> Juergen