db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-3856) difference between Embedded vs DerbyNetClient in format of return from timestamp(cast(? as varchar(32)))
Date Mon, 07 Jun 2010 13:53:46 GMT

    [ https://issues.apache.org/jira/browse/DERBY-3856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12876242#action_12876242
] 

Knut Anders Hatlen commented on DERBY-3856:
-------------------------------------------

IJ uses getString() and not getTimestamp() to fetch the timestamps. SQLTimestamp.getString()
uses a cached string value, or generates a new string representing the timestamp if a cached
string value is not available. The method that parses the timestamp for the TIMESTAMP function
(SQLTimestamp.parseTimestamp()) initializes the cached string value to the input string.

The reason why the result is different on embedded and client, is that the network server
uses getTimestamp() instead of getString() to access the value that it sends to the client,
so a normalized timestamp string is seen on the client.

The two statements that give different results on the embedded driver, differ because the
statement without a cast parses the timestamp at compile time and the one with a cast parses
the timestamp at execution time. The timestamp in the first statement is represented by a
java.sql.Timestamp in the execution plan, so that the input string is not preserved and a
normalized timestamp string will be returned instead. The statement with the cast will do
the parsing at execution time and return the SQLTimestamp returned from the parse method,
which has cached the original input string.

> difference between Embedded vs DerbyNetClient in format of return from timestamp(cast(?
as varchar(32)))
> --------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-3856
>                 URL: https://issues.apache.org/jira/browse/DERBY-3856
>             Project: Derby
>          Issue Type: Bug
>          Components: SQL
>    Affects Versions: 10.3.3.1, 10.4.2.0, 10.5.1.1
>            Reporter: Myrna van Lunteren
>
> There is a slight difference in how Embedded vs. DerbyNetClient return a specific cast.
> This showed up during conversion of the test lang/datetime.sql which before was only
run with Embedded...
> The following sql: 
> prepare dateTimePS as 'values( date(cast(? as integer)),timestamp(cast(? as varchar(32))))';
> execute dateTimePS using 'values(cast(1 as integer), ''2003-03-05-17.05.43.111111'')';
> gives:
>                                1         |2                         
>                                -------------------------------------
> Embedded:         1970-01-01|2003-03-05-17.05.43.111111
> DerbyNetClient:  1970-01-01|2003-03-05 17:05:43.111111
> (in Embedded there's a '-' between date and time part, with DerbyNetClient a space; with
Embedded the separator between time elements is ., with DerbyNetClient :. Embedded reflects
the data as passed in, with DerbyNetClient it seems to be the default timestamp format).
> I am not sure which is correct at this point, but I confirmed the behavior is like this
in latest builds of trunk and 10.3 and 10.4 branches.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message