Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Development" <derby-dev@db.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
Date: Tue, 22 Mar 2005 22:05:32 +0530
From: Shreyas Kaushik <Shreyas.Kaushik@sun.com>
Subject: Re: [PATCH] Derby-174
In-reply-to: <d9619e4a0503220715f3adf3d@mail.gmail.com>
To: Derby Development <derby-dev@db.apache.org>
Message-id: <42404954.9060003@sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
User-Agent: Mozilla Thunderbird 1.0 (X11/20041206)
References: <423FD14D.6020607@Sun.com>
 <d9619e4a0503220715f3adf3d@mail.gmail.com>

Hi Mamta,

  Thanks for your comments.
 
Currently the *setInto* method is not overridden in SQLTimestamp.java, 
hence it uses the one defined in DataType.java which is as shown below,

public void setInto(PreparedStatement ps, int position) throws 
SQLException, StandardException {

        ps.setObject(position, getObject());
    }

Here there is a call to getObject() which is overridden in 
SQLTimestamp.java  which calls getTimestamp((Calendar)null); which 
returns null.
Since the setObject cannot take an utyped null ( according to JDBC 3.0 
spec )  it throws an Exception.
So calling setInto in this case is equivalent to calling

ps.setTimestamp(position, getTimestamp((Calendar) null));

So whenever setInto is called on a Timestamp it is as if I am calling the above code.

~ Shreyas


Mamta Satoor wrote:

>On Tue, 22 Mar 2005 13:33:25 +0530, Shreyas Kaushik
><Shreyas.Kaushik@sun.com> wrote:
>  
>
>>Find the patch for this attached. I will send the test patch in a
>>seperate mail.
>>
>>~ Shreyas
>>
>>
>>Index: java/engine/org/apache/derby/iapi/types/SQLTimestamp.java
>>===================================================================
>>--- java/engine/org/apache/derby/iapi/types/SQLTimestamp.java   (revision 158017)
>>+++ java/engine/org/apache/derby/iapi/types/SQLTimestamp.java   (working copy)
>>@@ -45,12 +45,7 @@
>>import org.apache.derby.iapi.types.SQLDouble;
>>import org.apache.derby.iapi.types.SQLTime;
>>
>>-import java.sql.Date;
>>-import java.sql.Time;
>>-import java.sql.Timestamp;
>>-import java.sql.Types;
>>-import java.sql.ResultSet;
>>-import java.sql.SQLException;
>>+import java.sql.*;
>>
>>import java.util.Calendar;
>>import java.util.GregorianCalendar;
>>@@ -989,5 +984,10 @@
>>               currentCal.setTime(value);
>>               return SQLTime.computeEncodedTime(currentCal);
>>       }
>>+
>>+    public void setInto(PreparedStatement ps, int position) throws SQLException, StandardException {
>>+
>>+               ps.setTimestamp(position, getTimestamp((Calendar) null));
>>+       }
>>}
>>
>>
>>
>>    
>>
>
>Hi Shreyas,
>
>Haven't looked into details of current implementation of setInto
>methods by other datatypes, but I did notice that most other datatypes
>have coded setInto method as follows
>//this method is from SQLDecimal.java
>public final void setInto(PreparedStatement ps, int position) throws
>SQLException {
>	if (isNull()) {
>		ps.setNull(position, java.sql.Types.DECIMAL);
>		return;
>	}
>	ps.setBigDecimal(position, getBigDecimal());
>}
>
>Seems like they first check for isNULL and call different methods
>depending on whether the method is dealing with null or not. Wondered
>why your patch does not check for null before calling ps.setTimestamp
>method?
>
>Mamta
>  
>