David Graham wrote:
--- Ronald Dauster <[EMAIL PROTECTED]> wrote:The purpose of the enum is to be used as element of the params array which needs Objects and
[...]
As an alternative to trying to guess the correct type, there could be typed null-values
that can optionally be used by a client of QueryRunner. Something along
the lines public class Nulls { public static final Nulls VARCHAR = new Nulls(Types.VARCHAR); .... public int getType() {...} }
and in fillStatement
if (params[i] instanceof Nulls) {
setNull(i+1, ((Nulls) param[i]).getType());
} else if (params[i] != null) {
setObject
} else {
setNull
}
I'm not sure we need an enum Nulls class to wrap Types.* constants. IMO,
Types.VARCHAR ist an int. But I agree that it is a rather cumbersome to use and not exactly in
the spirit of dbutils.
it would be more straightforward to have a QueryRunner.setNullType(int)Good enough, if the dbutils client _knows_ which dataabase it is working with. Not so good, if the
method where you could pass in Types.VARCHAR. QueryRunner.fillStatement()
would then use your type instead of Types.OTHER.
Datasource is externally configured.
In addition, the class is documented to be thread-safe _and_ can be used with different connections.
Adding state to the class with setNullType will create a race condition in the (admittely contrived)
case where one instance of QueryRunner is used with Connections to databases that require
different null types.
I need to do a few portability tests against several DBMS anyway and could add that to my listFYI, Oracle's driver doesn't work with Types.OTHER either but it accepted every other type I tried (INTEGER, VARCHAR, etc).
(i. e. wich type works), but not before next week and definitely not agains DB2 or Postgres.
If someone can fill the gaps, maybe we find a type that works on all major databases.
David
Ronald
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
