[
https://issues.apache.org/jira/browse/DERBY-3173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12902826#action_12902826
]
Knut Anders Hatlen commented on DERBY-3173:
-------------------------------------------
Thank you, Eranda. The patch looks fine to me, but I think there's a small
problem with this change in SQLTime:
@@ -551,7 +526,6 @@
else if( hour > 12)
throw StandardException.newException(
SQLState.LANG_DATE_RANGE_EXCEPTION);
}
- valueString = parser.checkEnd();
encodedTime = computeEncodedTime( hour, minute, second);
}
else
The call to checkEnd() performs some extra input validation that we shouldn't
remove. For example, the following query used to be rejected:
ij> values time('05 am pm');
ERROR 22007: The syntax of the string representation of a datetime value is
incorrect.
With the patch, the query is now accepted:
ij> values time('05 am pm');
1
--------
05:00:00
1 row selected
Instead of removing that line completely, I think we should keep the call to
checkEnd() and just discard the return value.
> 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
> Assignee: Eranda Sooriyabandara
> Priority: Minor
> Attachments: Derby-3173.diff, Derby-3173.diff, sqldate.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.
