db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "dev@xx" <...@proxiflex.fr>
Subject Re: nulls in prepared statement
Date Thu, 21 Jul 2011 16:28:28 GMT
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

View raw message