Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: neutral (herse.apache.org: local policy)
Message-ID: <45EDB2B6.3060806@sbcglobal.net>
Date: Tue, 06 Mar 2007 10:28:06 -0800
From: Mike Matrigali <mikem_app@sbcglobal.net>
Reply-To: mikem_app@sbcglobal.net
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: derby-dev@db.apache.org
Subject: Re: PreparedStatement.setXXX methods do not set up ContextStack.
 Is that right and if so, why?
References: <d9619e4a0703030118m4bcc0847s92162cacfb1cee75@mail.gmail.com>
	 <45E9B178.3030902@apache.org>
	 <d9619e4a0703042248u49e16c08x76c403ca0313dc1f@mail.gmail.com>
	 <45EC5711.9030200@apache.org>
	 <d9619e4a0703060752k43f1619ehe5c9283fdf7de69@mail.gmail.com>
	 <45ED98EF.6070309@apache.org>
 <d9619e4a0703060921k6dc8141m12ce03f9971906db@mail.gmail.com>
In-Reply-To: <d9619e4a0703060921k6dc8141m12ce03f9971906db@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

 From the function spec I thought that this project was simply going to
implement TERRITORY_BASED ordering - and not anything to do with
changing string representation of datatypes based on the TERRITORY.
So I was expecting only the compare routines to be affected.

Is the problem that some dormant code is going to be enabled as a side
effect when the ordering changes go in?

Mamta Satoor wrote:
> Let me throw out my thoughts on how I am thinking of implementing locale 
> based ordering.
>  
> Since the goal is to not penalize the default mode of ordering, which is 
> UCS_BASIC, I am thinking that at the compile phase of a sql statement, 
> if we are dealing with a database with TERRITORY_BASED ordering, then I 
> will create super classes of char datatypes and these super classes will 
> use the locale info in their ordering sensitive methods which would be 
> methods like "like", string compare etc. So, these superclasses will 
> look a little bit like existing disabled national char datatypes but 
> will not have all the methods from the existing national char datatypes. 
> This way, the existing char datatypes will not have to know about 
> language based ordering and it will all be handled in the special 
> classes if user has asked for TERRITORY_BASED ordering.
>  
> I have to admit that I had assumed that locale info is already available 
> to the datatypes since the working National character type 
> implementation was already part of Derby except that it was disabled. I 
> had assumed that the locale info which is already available in the Derby 
> code will be simply used by the super classes of char datatypes. I had 
> not forseen the current problem of finding an efficient way of getting 
> the locale information to the datatypes. Which is fine because I do see 
> that it is important from Derby's performance point of view.
>  
> Please let me know what you think of the my design thoughts.
> thanks,
> Mamta
>  
> ps
> Also, in my earlier mail today, when I said that the solution that is 
> coming to my mind is context based, I didn't mean to push and pop the 
> contexts for setString methods because I realize that we have to pay 
> high penalty in terms of performance for the entire context pushing and 
> popping. Instead, I was thinking of having this special context on the 
> context stack for each booted database in the system which is never 
> popped out and just has the locale information in it and the locale 
> sensitive methods will somehow get that locale info from the context 
> stack. I have not gone the route of implementing it to know what is 
> involved for a solution like that.
>  
>  
> On 3/6/07, *Daniel John Debrunner* <djd@apache.org 
> <mailto:djd@apache.org>> wrote:
> 
>     Mamta Satoor wrote:
>      > I have spent some time exploring the code to see how the Locale
>     info can
>      > be passed to a datatype's locale sensitive methods. What I am
>     finding is
>      > that these locale sensitive methods, for instance setValue method in
>      > datatype like SQLTime, get called from many different places in the
>      > Derby code. Now, I might be single tracking my thoughts here, but it
>      > seems to me that context stack might be the right way for these
>      > different callers to get handle of locale info and pass it to the
>      > setValue methods. Maybe there are some other solutions too which
>     I am
>      > not able to visulaize at this point.
> 
>     Is there a list of logical operations/method calls/classes that need
>     locale based information, and what type of information they need?
> 
>     Is there some design or thoughts on how locale based ordering
>     (DERBY-1478) is going to be implemented?
> 
>     I'm not sure I understand the scope of the problem here.
> 
>     Dan.
> 
>