Kris Jurka wrote:
>
> On Wed, 13 Oct 2004, Oliver Jowett wrote:
>
>
>>I'd like to catch those errors earlier than query execution if possible.
>>If nothing else, it'll encourage application developers to provide
>>correct type info to the driver in all cases..
>
>
> I don't see the real benefit of catching this one statement earlier. It's
> still a runtime failure.
My point was that it is useful to generate an error on *all* uses of
untyped nulls, so that the developer sees the error in all cases
regardless of the database state or statement context.
Consider, for example, framework code that calls user-specified or
user-provided functions. If it uses untyped nulls, and the driver uses
Oid.UNKNOWN, you will only see the problem when the framework tries to
pass a NULL to an overloaded function. If the driver rejects the call
with an error in all cases where a NULL is used, then the framework
developer sees the error as soon as they exercise the NULL path,
regardless of whether their test environment has overloaded functions or
not.
====
The spec has this to say about the setObject case:
>> If setObject is called without a type parameter, the Java Object is
>> implicitly mapped using the default mapping for that object type.
There is no default mapping (in appendix B table B-4) for Java nulls.
Of course the spec then goes on to say:
>> If a Java null is passed to any of the setter methods that take a Java
>> object, the parameter will be set to JDBC NULL.
I don't know which takes precedence. The way that setNull() is organized
implies that JDBC requires NULLs to be typed, but there's nothing
explicit about it.
-O
