Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
Date: Mon, 04 Sep 2006 15:26:36 +0200
From: "Bernt M. Johnsen" <Bernt.Johnsen@Sun.COM>
Subject: Re: [jira] Commented: (DERBY-889) with client getTimestamp on a TIME
 column will print the date  1900-01-01 instead of the current date
In-reply-to: <27706864.1157297843496.JavaMail.jira@brutus>
Sender: Bernt.Johnsen@Sun.COM
To: derby-dev@db.apache.org
Reply-to: Bernt.Johnsen@Sun.COM
Message-id: <44FC298C.9010303@Sun.COM>
Organization: Sun Microsystems
MIME-version: 1.0
Content-type: multipart/signed;
 boundary=------------enigBE7FD69A3B65F6D292728EA1;
 protocol="application/pgp-signature"; micalg=pgp-sha1
References: <27706864.1157297843496.JavaMail.jira@brutus>
User-Agent: Thunderbird 1.5.0.5 (X11/20060831)


--------------enigBE7FD69A3B65F6D292728EA1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Bryan Pendleton (JIRA) wrote:
>     [ http://issues.apache.org/jira/browse/DERBY-889?page=3Dcomments#ac=
tion_12432344 ]
>
> Bryan Pendleton commented on DERBY-889:
> ---------------------------------------
>
> Hi Dan, thanks for the feedback and pointers.
>
> Yes, behavior (C): the current date at the time the getTimestamp() is c=
alled, is the
> behavior that I was attempting to achieve with the patch.

I would say C is an ok approach from a practical point of view, although =
D would be the ideal solution,
since then the following two cases would have equal behaviour:

PreparedStatement P =3D c.prepareStatement("select timeCol from verylonge=
ndcomplexoperation");
ResultSet rs =3D p.execute();
java.sql.Timestamp ts =3D rs.getTimestamp(1);

and

PreparedStatement P =3D c.prepareStatement("select CAST(timeCol AS TIMEST=
AMP) from verylongendcomplexoperation");
ResultSet rs =3D p.execute();
java.sql.Timestamp ts =3D rs.getTimestamp(1);

>
> Am I understanding correctly that your idea with DERBY-1811 is to split=
 this issue
> into a client issue (DERBY-889) and an embedded issue (DERBY-1811)? Tha=
t
> seems like a good plan to me.
>
> Regarding your critique of the EmbedResultSet change, I agree that it i=
s undesirable
> to lose the optimization of re-using the shared Calendar object, and I =
agree that it
> leaves a hole in that it doesn't actively ensure any particular value f=
or the DATE portion
> in the case of getTimestamp(<TIME column>, cal).
>
> It sounds like your preferred fix for DERBY-1811 would be:
>  - always re-use the cached calendar object if the user does not pass o=
ne in
>  - set the date portion of the calendar object (either the cached one o=
r the user-provided one)
>    to contain the current date when converting a TIME value into a TIME=
STAMP
>
> Thanks for your continued review and your help understanding the intend=
ed behavior.
>
>
>> with client getTimestamp on a TIME column will print the date  1900-01=
-01 instead of the current date
>> ----------------------------------------------------------------------=
-------------------------------
>>
>>                 Key: DERBY-889
>>                 URL: http://issues.apache.org/jira/browse/DERBY-889
>>             Project: Derby
>>          Issue Type: Bug
>>          Components: Network Client
>>    Affects Versions: 10.1.2.1, 10.1.2.2, 10.2.1.0, 10.1.3.0
>>            Reporter: Kathey Marsden
>>         Assigned To: Bryan Pendleton
>>         Attachments: derby-889-updated-Aug-2006.diff, derby-889.diff
>>
>>
>> On client getTimestamp on a TIME column will print date   1900-01-01 i=
nstead of the current date like the embedded driver.
>> To repro run the DERBY-877 repro without specifying a file.encoding
>> java TestEnc derbynetclient
>> [snip]
>> COLUMN 2:TM TIME
>>         getString:      16:27:35
>>         getTimeStamp:   1900-01-01 16:27:35.0
>>         getTime:        16:27:35
>>         getDate         Exception SQLSTATE:null  (EXPECTED)
>> With Embedded  it prints the current date for getTimestamp
>> java TestEnc  derby
>> COLUMN 2:TM TIME
>>         getString:      16:27:35
>>         getTimeStamp:   2006-01-28 16:27:35.0
>>         getTime:        16:27:35
>>         getDate         Exception SQLSTATE:22005  (EXPECTED)
>


--=20
Bernt Marius Johnsen, Database Technology Group,
Staff Engineer, Technical Lead Derby/Java DB
Sun Microsystems, Trondheim, Norway


--------------enigBE7FD69A3B65F6D292728EA1
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (GNU/Linux)
Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org

iD8DBQFE/CmPlFBD9TXBAPARAqCFAJ98qcBNyMMSIDe8qHMd0B0rVWzU/ACfU50G
Y06WAv1co2JPCdu3wUcmGMg=
=jAzl
-----END PGP SIGNATURE-----

--------------enigBE7FD69A3B65F6D292728EA1--