Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <1842676020.1205877864566.JavaMail.jira@brutus>
Date: Tue, 18 Mar 2008 15:04:24 -0700 (PDT)
From: "Daniel John Debrunner (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Reopened: (DERBY-2720) remove dead code associated with
 unsupported National Char implementation
In-Reply-To: <12772592.1180460595569.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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