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:
<[EMAIL PROTECTED]> 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));
+ }
}
+
