[
https://issues.apache.org/jira/browse/DERBY-3173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12890800#action_12890800
]
Knut Anders Hatlen commented on DERBY-3173:
-------------------------------------------
Dan wrote:
> In addition I think the getString() will sometimes return a
> non-normalized form, if the value is set by a non-standard format
> then the cached String is set to the non-standard format, not the
> standard format, I believe this is incorrect.
This part of the issue sounds like the problem that caused DERBY-3856,
which has later been fixed.
> Removed cached String objects from SQLDate, SQLTime and SQLTimestamp
> --------------------------------------------------------------------
>
> Key: DERBY-3173
> URL: https://issues.apache.org/jira/browse/DERBY-3173
> Project: Derby
> Issue Type: Improvement
> Components: SQL
> Reporter: Daniel John Debrunner
> Priority: Minor
>
> These type classes save a copy of the value when it is converted to a String
> (e.g. through a ResultSet.getString()). This complicates the code & increases
> memory use for little value, in most cases the cached value will never be
> used. E.g. for any type of scan the String value will be discarded when
> moving to the next row. In most cases applications do not call getString()
> twice on a column.
> The code has some historical basis in the fact that these types used to be
> represented by a java.sql.Time/Date/Timestamp object and its conversion to
> String was slow. Now the conversion of all these types to a String is simple.
> In addition I think the getString() will sometimes return a non-normalized
> form, if the value is set by a non-standard format then the cached String is
> set to the non-standard format, not the standard format, I believe this is
> incorrect.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
