[
https://issues.apache.org/jira/browse/DERBY-3173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eranda Sooriyabandara updated DERBY-3173:
-----------------------------------------
Attachment: Derby-3173.diff
Hi Knut,
According to your guidance I came up with a patch to remove caching the value
of SQLDate. Is it what you expected?
thanks
> 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
> Attachments: Derby-3173.diff
>
>
> 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.
