[
https://issues.apache.org/jira/browse/DERBY-2720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12559991#action_12559991
]
Mamta A. Satoor commented on DERBY-2720:
----------------------------------------
The checkin above caused test failure in SetObjectUnsupportedTest which runs
under JDK1.6. Unfortunately, I ran my tests only with JDK1.4 and hence I didn't
catch the problem before checkin. I just fixed the problem with revision 612865
in trunk. Will work on migrating it to 10.3 The commit comments for trunk were
as follows
While working on DERBY-2720, I removed national datatypes as one of the
unsupported data types(revision 612525) and that caused the test failure for
SetObjectUnsupportedTest since we stopped recognizing national dataypes as one
of the unsupported datatypes. The fix required changes in only one class which
I had modified incorrectly in revision 612525. This test failure was not caught
earlier by my local runs of the test because I had used JDK14 which has JDBC3
support and this paritcular test requires JDBC4 support.
> remove dead code associated with unsupported National Char implementation
> -------------------------------------------------------------------------
>
> Key: DERBY-2720
> URL: https://issues.apache.org/jira/browse/DERBY-2720
> Project: Derby
> Issue Type: Improvement
> Components: SQL
> Reporter: Mike Matrigali
> Assignee: Mamta A. Satoor
> Priority: Minor
> Fix For: 10.3.2.2, 10.4.0.0
>
>
> Derby still has some untested, unused code relating to a non-standard
> implementation of a Nationa Char type. The current code can be removed.
> I believe the interesting functionality associated with this is now provided
> by DERBY-1478 (territory based collation) . If Derby ever implements a
> National Char type it should do so differently than the existing code,
> collation should not be tied to the National Char type.
> I believe a future National char type might have to maintain a separate type
> id for compatibility with jdbc interface, but actual implmentation should be
> the same code as the char types. Collating of the the national char type
> should be supported in exactly same way as regular char types.
> If anyone is really intested in the national char code, it's history will
> always be available in svn, and a consistent version is available by looking
> at 10.0, 10.1,
> and 10.2 codelines. I would propose any removal of code only take place in
> trunk and not be backported to a released codeline.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
