db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: PreparedStatement.setXXX methods do not set up ContextStack. Is that right and if so, why?
Date Tue, 06 Mar 2007 18:28:06 GMT
 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.

View raw message