db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mamta Satoor" <msat...@gmail.com>
Subject Re: PreparedStatement.setXXX methods do not set up ContextStack. Is that right and if so, why?
Date Tue, 06 Mar 2007 17:21:50 GMT
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> 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.
>
>

Mime
View raw message