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* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> 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.
