db-derby-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Db-derby Wiki] Update of "BuiltInLanguageBasedOrderingDERBY-1478" by MamtaSatoor
Date Fri, 30 Mar 2007 20:36:49 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Db-derby Wiki" for change notification.

The following page has been changed by MamtaSatoor:
http://wiki.apache.org/db-derby/BuiltInLanguageBasedOrderingDERBY-1478

------------------------------------------------------------------------------
  NOTE : This page is currently collection of all the known line items in a random order.
Once I have them all jotted down, I will then organize them into sub-sections and then send
an email to the list. In the mean time, I appreciate people on the list going through these
lineitems as they are listed and asking questions because it points out areas that I might
not have thought of. 
  
  == Design proposals ==
- In 10.3, a user might create a table with CHAR datatypes along with other datatypes. The
task at hand is if the user has asked for territory based collation, then we want these CHAR
datatypes to collate differently than the CHAR datatypes that exist today in 10.2 And if the
user hasn't requested territory based collation, then we want these CHAR datatypes to collate
the way they do in 10.2 today. So, in short, the CHAR datatype in 10.3 will have different
collation behavior depending on what user has requested. But as far as the user is concerned,
they are just SQL CHAR datatypes and not new SQL datatypes. 
+ In 10.3, a user might create a table with CHAR datatypes along with other datatypes. The
task at hand is if the user has asked for territory based collation, then we want these CHAR
datatypes to collate differently than the CHAR datatypes that exist today in 10.2 And if the
user hasn't requested territory based collation, then we want these CHAR datatypes to collate
the way they do in 10.2 today. So, in short, the CHAR datatype in 10.3 will have different
collation behavior depending on what user has requested at the database create time. But as
far as the user is concerned, they are just SQL CHAR datatypes and not new SQL datatypes.

   
  In the original proposal, the intention was to introduce new internal CHAR datatype which
extended current CHAR datatype in Derby. This would have been implemented by having a new
format id associated with the new internal CHAR datatypes. But with that proposal, there was
overhead associated with implementing new getter methods in DataValueFactory for this new
internal datatype and the type compiler associated with the new internal datatype etc. The
other issue with the proposal was that there are many places in the code today where we get
character datatypes and all of those cases will have to be inidividually investigated to see
which CHAR datatype implementation they should use. So, if the character datatype is getting
instantiated for CHAR columns in system tables, then we should use existing CHAR datatype
implementation. But, if they were getting instantiated for user table, then the new internal
CHAR datatype should be instantiated. AND there will be places where we c
 an't determine which one of the two CHAR implementations should we use, for eg a string value
in a query 'abc'. 
   

Mime
View raw message