Re: [Springframework-developer] SqlTypeValue and SqlLobValue

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

Thomas, Juergen,

I've experimented a bit with the new SqlTypeValue support, and I 'm
wondering why only the sqlType is being passed as a parameter to
setTypeValue, but not the typeName...

When using an inner class implementation - which I don't actually agree
would be typical usage - you usually already know the sqlType;
otherwise, you usually need the typeName as well. Note that the typeName
"NUMBERS" is duplicated in the javadoc example.

The AbstractSqlTypeValue class is very convenient, but at least the
typeName, and probably also the sqlType would need to be passed to
createTypeValue().

So I suggest changing the respective signatures to:

void setTypeValue(PreparedStatement ps, int paramIndex, int sqlType,
String typeName) throws SQLException;

protected abstract Object createTypeValue(Connection con, int sqlType,
String typeName) throws SQLException;

This would allow "flexible" custom SqlTypeValues to be implemented:

public class OracleArraySqlTypeValue extends AbstractSqlTypeValue {
    private final Object value;

    public OracleArraySqlTypeValue(Object value) {
        this.value =3D value;
    }

    protected Object createTypeValue(Connection con, int sqlType, String
    typeName) throws SQLException {
        if (sqlType !=3D Types.ARRAY) {
            throw new IllegalArgumentException("only SQL Type ARRAY is
            supported by " + getClass());
        }
        return new ARRAY(ArrayDescriptor.createDescriptor(typeName,
        con), con, value);
    }
}

Unlike when using an inner class, the actual application classes are now
no longer dependent on Oracle classes. Moreover, you don't need to
copy-paste the implementation every time ;-)

Another issue I encountered is that both the PreparedStatement and
Connection are not the native, but wrapped objects. (I was using a
SqlQuery object and a Commons DBCP connection pool.)
Is it the responsibility of the SqlTypeValue implementation to unwrap
these, or could that be done by JdbcTemplate? I suppose most
SqlTypeValue implementations would need the native objects, and as they
are throw-away objects created with "new", you can't just wire the
NativeJdbcExtractor to them...

I think refactoring SqlLobValue as a (Disposable)SqlTypeValue was an
excellent idea :-)
I've tried some blob operations on Oracle, and everything still seems to
work (OracleLobHandler has its own NativeJdbcExtractor!). These weren't
extensive tests though...

Grateful if you could have a look at these issues!

Kind regards,
Tom.

On Mon, 28 Jun 2004 09:21:26 +0200, "j=FCrgen h=F6ller [werk3AT]"
<jue...@we...> said:
> Thomas,
>=20=20
> I've just committed a refactoring of the SqlTypeValue and SqlLobValue
> stuff. We had some package cross-dependencies there that I resolved
> (between jdbc.core and jdbc.support, caused by SqlTypeValue residing in
> jdbc.core but jdbc.support.JdbcUtils accessing it).
>=20=20
> I've gone beyond that in that I made SqlLobValue a subclass of
> SqlTypeValue: All the parameter value code (now in
> jdbc.core.StatementCreatorUtils rather than jdbc.support.JdbcUtils) needs
> to worry about is SqlTypeValue; it will automatically cover SqlLobValue
> too. Consequently, SqlLobValue resides in jdbc.core.support now
> (alongside AbstractLobCreatingPreparedStatementCallback and
> AbstractLobStreamingResultSetExtractor), as there's no need for any class
> in jdbc.core to know about it.
>=20=20
> Furthermore, SqlTypeValue is an interface now: I strongly believe that it
> should be an interface rather than an abstract class. For typical usage
> as inner class, there is no need for a value property in the first
> place... I've also added an AbstractSqlTypeValue class to
> jdbc.core.support that pre-implements the setTypeValue method by
> delegating to an " Object createTypeValue(Connection con)" method
> (assuming to be set with PreparedStatement.setObject).
>=20=20
> I hope you're happy with the changes; please have a look at them and tell
> me what you think. I hope I didn't misunderstand the purpose of
> SqlTypeValue, but I guess it's desirable to have it unified with
> SqlLobValue.It would also be good to run them against some Oracle samples
> once again :-)
>=20=20
> I've also noticed that there aren't specific unit tests for SqlTypeValue
> and SqlLobValue yet. We need to add some till 1.1 RC1. I've tested the
> new classes against our "imagedb" sample on MySQL, BTW, playing with
> various BLOB/CLOB access strategies.
>=20=20
> Juergen
>=20=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> digital self defense, top technical experts, no vendor pitches,
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer