Well I don't think you can redefine the classes used by the database driver.
What I use is wrapper classes for PreparedStatement instances.
BTW it has been very useful when Derby change the way they manage setBoolean
when column data type is a string type.
Before 10.8.2 setBoolean was setting '0' or '1'. From 10.8.2, setBoolean set
'true' or 'false' !!
I have had to change just one line of code to keep the same behaviour.
public void setBoolean( int index, boolean value )
{
// stmt.setBoolean( index, value ) ;
stmt.setInt( index, param ? 1 : 0 ) ;
}
----- Original Message -----
From: Tomcat Programmer
To: Derby Discussion ; Tomcat Programmer
Sent: Thursday, July 21, 2011 5:31 PM
Subject: Re: nulls in prepared statement
>
> Well may be you won't have less ugly code, but at least it will be hidden
;-)
>
> I think the easiest way it to use you own PreparedStatement class. So you
can do
> any special treatment or workaround in a centralized and unique place.
>
Hi JYL this is a very insightful and interesting solution, which I would not
have thought of. Is this as simple as creating my own class with the derby
version as its superclass and then just overriding the method? That seems too
easy .. is there any catches or pitfalls you can give me a heads up on? Thanks
again for your help!
Adding one specific thought: if I extend the class, how do I get my version
to be instantiated? (this is a web application and so it will be picking up
driver registration and so forth from JNDI.)
