Armin Waibel wrote:
If this is the case I think the driver has a somewhat weird class
structure...
this could be the case, but there is no rule that say "don't do this
it's evil" ;-)
Are you sure? My hope is that an in-depth search of the JDBC specification
will actually say that "returning CallableStatement from a
Connection#prepareStatement is evil and not allowed".
Maybe not with that exact wording. :)
But just looking at the API docs I can't find what I want to find, only:
http://java.sun.com/j2se/1.4.2/docs/api/java/sql/Connection.html#prepareStatement(java.lang.String,%20int,%20int)
That says that prepareStatement _must_ return instanceof PreparedStatement.
And:
http://java.sun.com/j2se/1.4.2/docs/api/java/sql/CallableStatement.html
That says that CallableStatement extends PreparedStatement.
So in theory, just from reading the API docs, it looks like the driver
is not evil...
Maybe you could try to write a really small stand-alone JDBC test class
and debug Connection#prepareStatement vs Connection#prepareCall and see
if there is anything in the class structure that can be used to separate
the two?
hmm, I don't like this. I think the assumption made in
Platform.isCallableStatement is wrong, this is the problem not the
driver implementation class (in next version of the driver tis can
change....).
IMO it's a fault in the driver if it does this, but as you say:
if the JDBC spec does not explicitly forbid this it is allowed and OJB
have to face the fact that some drivers might or might not conform
to the "de-factor" standard of not downcasting non-callable
PreparedStatement to also implement CallableStatement.
BTW: is this really the default MaxDB driver behaviour? No special config?
Maybe Vadim has more input re. your suggested solution to read the info
from the OJB descriptors instead?
Regards,
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
