db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Satheesh Bandaram <sathe...@Sourcery.Org>
Subject Re: [PATCH] Derby-174
Date Tue, 29 Mar 2005 23:11:46 GMT
I have submitted this patch. Thanks for adding new test case to test
both. But the new test is not part of any test suite, so it may not get
run even though it is there.  Can you add the test case into 'jdbcapi'
or 'derbylang' test suites?

Sending        java\engine\org\apache\derby\iapi\types\SQLBlob.java
Sending        java\engine\org\apache\derby\iapi\types\SQLTimestamp.java
Adding        
java\testing\org\apache\derbyTesting\functionTests\master\prepStmtNull.out
Adding        
java\testing\org\apache\derbyTesting\functionTests\tests\jdbcapi\prepStmtNull.java
Transmitting file data ....
Committed revision 159445.

Shreyas Kaushik wrote:

> Sateesh,
>
> Did you have a chance to look into this?
>
> ~ Shreyas
>
> Shreyas Kaushik wrote:
>
>> Attached is the latest patch with the changes.
>>
>> thanks
>> Shreyas
>>
>> Satheesh Bandaram wrote:
>>
>>> I will submit your patches after your changes.
>>>
>>> Satheesh
>>>
>>> Shreyas Kaushik wrote:
>>>
>>>  
>>>
>>>> I guess this is an IDE trick , I'll change this.
>>>>
>>>> ~ Shreyas
>>>>
>>>> Army wrote:
>>>>
>>>>  
>>>>
>>>>> <Shreyas.Kaushik@sun.com> wrote
>>>>>
>>>>>    
>>>>>
>>>>>> -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.*;
>>>>>>       
>>>>>
>>>>>
>>>>>
>>>>> I apologize if this is overly picky, but isn't inclusion of a package
>>>>> via the "*" wildcard generally considered an unfavorable programming
>>>>> practice?  I think it's fine to do so when writing tests, but as far
>>>>> as I know, the Derby codeline generally avoids using wildcard
>>>>> imports.  And even if there are existing places where such imports
>>>>> are used, it seems to me that _replacing_ existing imports with the
>>>>> wildcard import is probably not a habit to encourage.
>>>>>
>>>>> Even if functionally speaking there's no difference, to do this is to
>>>>> introduce a style of imports that's doesn't agree with the rest of
>>>>> the codeline--is that something to avoid?
>>>>>
>>>>> 'Course, maybe that's just unfounded paranoia on my part...
>>>>>
>>>>> *shrug*
>>>>> Army
>>>>>
>>>>>     
>>>>
>>>>
>>>>
>>>>   
>>>
>>>
>>>
>>>  
>>>
>> ------------------------------------------------------------------------
>>
>> 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,15 @@
>> 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.PreparedStatement;
>>
>> import java.util.Calendar;
>> import java.util.GregorianCalendar;
>> @@ -65,7 +68,7 @@
>> /**
>>  * This contains an instance of a SQL Timestamp object.
>>  * <p>
>> - * SQLTimestamp is stored in 3 ints - an encoded date, an encoded
>> time and + * SQLTimestamp is stored in 3 ints - an encoded date, an
>> encoded time and
>>  *        nanoseconds
>>  * encodedDate = 0 indicates a null WSCTimestamp
>>  *
>> @@ -989,5 +992,12 @@
>>         currentCal.setTime(value);
>>         return SQLTime.computeEncodedTime(currentCal);
>>     }
>> +
>> +    +    public void setInto(PreparedStatement ps, int position)
>> throws SQLException, StandardException {
>> +
>> +                  ps.setTimestamp(position, getTimestamp((Calendar)
>> null));
>> +     }
>> }
>>
>> +
>>  
>>
>
>
>


Mime
View raw message