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]> 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.
