db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel John Debrunner (JIRA)" <j...@apache.org>
Subject [jira] Reopened: (DERBY-2720) remove dead code associated with unsupported National Char implementation
Date Tue, 18 Mar 2008 22:04:24 GMT

     [ https://issues.apache.org/jira/browse/DERBY-2720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Daniel John Debrunner reopened DERBY-2720:

Some of the code that the national types (incorrectly) used to convert between datetime values
and national characters has not been removed.

E.g. the SQLChar.get{Date,Time.Timestamp}Format methods are not used (I think).
Removing these methods may show other methods not used and may progress to the date time methods
in LocaleFinder being removed.

I'm testing removing the getXXXFormat() methods.

> 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:,
> 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.

View raw message