Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <21875626.1176221612675.JavaMail.jira@brutus>
Date: Tue, 10 Apr 2007 09:13:32 -0700 (PDT)
From: "A B (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-2535) Make Locale available in
 DataValueFactory(DVF). This Locale object will be used to construct
 Collator object if the user has requested territory based collation.
In-Reply-To: <22177677.1176143373098.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-2535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12487808 ] 

A B commented on DERBY-2535:
----------------------------

Thank you for the patch, Mamta.  I took a quick look at it and I just have one question: with this patch we now call the new "setLocale()" method on the DataValueFactory that is created within the BasicDatabase.boot() method.  That part looks good.  My question arises from the fact that there are actually *two* places in the code where we create a DataValueFactory.  You've changed the first one, but there is another call in:

  sql/conn/GenericLanguageConnectionFactory.boot()

that looks identical to the one you've already changed.  Does this second DataValueFactory need to have its locale set, as well?  Or is it not required in this particular case?

I haven't looked into the code so maybe the "boot()" method in GenericLanguageConnectionFactory returns the same DVF that is created in BasicDatabase.boot()?  If that's the case then I can see why we do not need to set locale a second time.  But as I'm not familiar with this code, I thought I'd bring it up...

Also, I noticed that in the patch that you actually committed, the call to "setLocale()" is commented out (which is not the case in the patch that you posted).  Was that an intentional "incremental development" decision since the feature is not fully implemented yet?

> Make Locale available in DataValueFactory(DVF). This Locale object will be used to construct Collator object if the user has requested territory based collation.
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-2535
>                 URL: https://issues.apache.org/jira/browse/DERBY-2535
>             Project: Derby
>          Issue Type: New Feature
>          Components: SQL
>    Affects Versions: 10.3.0.0
>            Reporter: Mamta A. Satoor
>         Assigned To: Mamta A. Satoor
>         Attachments: DERBY2535_Set_Locale_On_DVF_v1_diff.txt, DERBY2535_Set_Locale_On_DVF_v1_stat.txt
>
>
> Add a new api on DVF which will make Locale object available to DVF. This new api on DVF will get called by the boot method of  BasicDatabase after BasicDatabase has finished booting DVF. This Locale will be either the Locale obtained from the territory attribute supplied by the user on the JDBC url at database create time or if user didn't provide the territory attribute at database create time, then it will be set to the default JVM locale. This Locale object will be used by DVF to construct the Collator object if user has requested territory based collation.
> The new api will look like following
>         void setLocale(Locale localeOfTheDatabase);

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.