|
From: <jue...@we...> - 2004-06-28 07:20:45
|
Thomas, =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 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 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 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 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 Juergen =20 |