From derby-commitsmichaelbecker@example.org Mon Apr 02 02:38:14 2007 Return-Path: <derby-commitsmichaelbecker@example.org> Delivered-To: michaelbecker@example.org Received: (qmail 25653 invoked from network); 2 Apr 2007 02:38:13 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 2 Apr 2007 02:38:13 -0000 Received: (qmail 65788 invoked by uid 500); 2 Apr 2007 02:38:21 -0000 Delivered-To: michaelbecker@example.org Received: (qmail 65717 invoked by uid 500); 2 Apr 2007 02:38:20 -0000 Mailing-List: contact michaelbecker@example.org; run by ezmlm Precedence: bulk list-help: <mailto:michaelbecker@example.org> list-unsubscribe: <mailto:michaelbecker@example.org> List-Post: <mailto:michaelbecker@example.org> Reply-To: "Derby Development" <michaelbecker@example.org> List-Id: <derby-commits.db.apache.org> Delivered-To: mailing list michaelbecker@example.org Received: (qmail 65706 invoked by uid 99); 2 Apr 2007 02:38:20 -0000 Received: from herse.apache.org (HELO herse.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 01 Apr 2007 19:38:20 -0700 X-ASF-Spam-Status: No, hits=-100.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [83.161.120.155] (HELO eos.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 01 Apr 2007 19:38:12 -0700 Received: from eos.apache.org (localhost [83.161.120.155]) by eos.apache.org (Postfix) with ESMTP id 6058859A07 for <michaelbecker@example.org>; Mon, 2 Apr 2007 02:37:52 +0000 (GMT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: Apache Wiki <michaelbecker@example.org> To: michaelbecker@example.org Date: Mon, 02 Apr 2007 02:37:52 -0000 Message-ID: <michaelbecker@example.org> Subject: [Db-derby Wiki] Update of "BuiltInLanguageBasedOrderingDERBY-1478" by MamtaSatoor X-Virus-Checked: Checked by ClamAV on apache.org 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 ------------------------------------------------------------------------------ 14)Make sure the space padding at the end of various character datatypes is implemented commented correctly in javadocs. This padding is used in collation related methods. For eg check SQLChar.stringCompare method. == Implemented items == - 1)A shell for subclass of SQLChar has been implemented and it is called CollatorSQLChar. It resides in derby.iapi.types package. This work was done by revisions 516864, 516869 and 518479. + 1)Subclasses with non-default-collation have been implemented for character types SQLChar, SQLVarchar, SQLLongvarchar and SQLClob. The new subcalsses are called CollatorSQLChar, CollatorSQLVarchar, CollatorSQLLongvarchar and CollatorSQLClob, respectively. They reside in derby.iapi.types package. This work was done by revisions 516864, 516869 and 518479, 524545. 2)At the time of database create time, optional JDBC url attribute COLLATION is validated by the boot code in data dictionary and the validated value of COLLATION(if none specified by user, then it will default to UCS_BASIC which is also the only collation available on pre-10.3 databases) attribute is saved as derby.database.collation property in the properties conglomerate. This work was done by revision 511283 From derby-commitsmichaelbecker@example.org Mon Apr 02 02:58:34 2007 Return-Path: <derby-commitsmichaelbecker@example.org> Delivered-To: michaelbecker@example.org Received: (qmail 30812 invoked from network); 2 Apr 2007 02:58:34 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 2 Apr 2007 02:58:34 -0000 Received: (qmail 82747 invoked by uid 500); 2 Apr 2007 02:58:41 -0000 Delivered-To: michaelbecker@example.org Received: (qmail 82720 invoked by uid 500); 2 Apr 2007 02:58:41 -0000 Mailing-List: contact michaelbecker@example.org; run by ezmlm Precedence: bulk list-help: <mailto:michaelbecker@example.org> list-unsubscribe: <mailto:michaelbecker@example.org> List-Post: <mailto:michaelbecker@example.org> Reply-To: "Derby Development" <michaelbecker@example.org> List-Id: <derby-commits.db.apache.org> Delivered-To: mailing list michaelbecker@example.org Received: (qmail 82709 invoked by uid 99); 2 Apr 2007 02:58:41 -0000 Received: from herse.apache.org (HELO herse.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 01 Apr 2007 19:58:41 -0700 X-ASF-Spam-Status: No, hits=-100.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [83.161.120.155] (HELO eos.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 01 Apr 2007 19:58:33 -0700 Received: from eos.apache.org (localhost [83.161.120.155]) by eos.apache.org (Postfix) with ESMTP id 1C92F59A07 for <michaelbecker@example.org>; Mon, 2 Apr 2007 02:58:13 +0000 (GMT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: Apache Wiki <michaelbecker@example.org> To: michaelbecker@example.org Date: Mon, 02 Apr 2007 02:58:12 -0000 Message-ID: <michaelbecker@example.org> Subject: [Db-derby Wiki] Update of "BuiltInLanguageBasedOrderingDERBY-1478" by MamtaSatoor X-Virus-Checked: Checked by ClamAV on apache.org 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 ------------------------------------------------------------------------------ 9)This item is related to item 11. When DVF gets called by store to create right DVD for given formatid and collation type, for formatids associated with character datatypes, it will first create the base character datatype class which is say SQLChar. Then it will call getValue method on the DVD with the RuleBasedCollator corresponding to the collation type as the parameter. (This RuleBasedCollator will be null for UCS_BASIC collation). The getValue method will return SQLChar or CollatorSQLChar depending on whether RuleBasedCollator is null or not. getValue is the new method which needs to be added to the interface StringDataValue. - 10)Override all the collation related methods in the CollatorSQLChar. CollatorSQLChar is a subclass of SQLChar. + 10)WorkHorseForCollatorDatatypes should override all the collation related methods so that it uses the non-default Collator. All the non-default-collation-sensitive classes have an instance of WorkHorseForCollatorDatatypes which is used to call the collation related methods. This ensures that these collation related methods are implemented in one central place rather than in all the collation-sensitive classes. - 11)Add subclasses for SQLVarchar, SQLLongvarchar, SQLClob. These subclasses will override the collation related methods in their superclasses. + 11)CollatorSQLChar has a method called getCollationElementsForString which currently gets called by like method. getCollationElementsForString gets the collation elements for the value of CollatorSQLChar class. But say like method is looking for pattern 'A%' and the value of CollatorSQLChar is 'BXXXXXXXXXXXXXXXXXXXXXXX'. This is eg of one case where it would have been better to get collation element one character of CollatorSQLChar value at a time so we don't go through the process of getting collation elements for the entire string when we don't really need. This is a performance issue and could be taken up at the end of the implementation. Comments on this from Dan and Dag can be found in DERBY-2416. - 12)CollatorSQLChar has a method called getCollationElementsForString which currently gets called by like method. getCollationElementsForString gets the collation elements for the value of CollatorSQLChar class. But say like method is looking for pattern 'A%' and the value of CollatorSQLChar is 'BXXXXXXXXXXXXXXXXXXXXXXX'. This is eg of one case where it would have been better to get collation element one character of CollatorSQLChar value at a time so we don't go through the process of getting collation elements for the entire string when we don't really need. This is a performance issue and could be taken up at the end of the implementation. Comments on this from Dan and Dag can be found in DERBY-2416. - - 13)Add tests for this feature. This a broad umbrella task but I do want to mention 3 specific tests that we should be testing + 12)Add tests for this feature. This a broad umbrella task but I do want to mention 3 specific tests that we should be testing a)Make sure the scale of the character datatypes is always 0 and it didn't get impacted negatively by the overloading of scale field as collation type in TypeDescriptor. b)Test case for recovery - have an outstanding transaction with insert/delete/updates that affect one or more character indexes (all with a collation setting that is different from default collation). Make sure those log records get to the log and then crash the server. Restarting the server will then run through the recovery code and will ensure that we test for correct collation usage at recovery time. Mike has put more info about this in DERBY-2336. c)CREATE VIEW should have collation type UCS_BASIC/TERRIOTRY_BASED assocatied with it's character columns. The exact collation will be determined by what is the value of the COLLATION attribute. This is same as what would happen for CREATE TABLE. Have a test for global temporary tables with character colums too. - 14)Make sure the space padding at the end of various character datatypes is implemented commented correctly in javadocs. This padding is used in collation related methods. For eg check SQLChar.stringCompare method. + 13)Make sure the space padding at the end of various character datatypes is implemented commented correctly in javadocs. This padding is used in collation related methods. For eg check SQLChar.stringCompare method. == Implemented items == 1)Subclasses with non-default-collation have been implemented for character types SQLChar, SQLVarchar, SQLLongvarchar and SQLClob. The new subcalsses are called CollatorSQLChar, CollatorSQLVarchar, CollatorSQLLongvarchar and CollatorSQLClob, respectively. They reside in derby.iapi.types package. This work was done by revisions 516864, 516869 and 518479, 524545. From derby-commitsmichaelbecker@example.org Mon Apr 02 03:09:23 2007 Return-Path: <derby-commitsmichaelbecker@example.org> Delivered-To: michaelbecker@example.org Received: (qmail 32645 invoked from network); 2 Apr 2007 03:09:22 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 2 Apr 2007 03:09:22 -0000 Received: (qmail 89338 invoked by uid 500); 2 Apr 2007 03:09:29 -0000 Delivered-To: michaelbecker@example.org Received: (qmail 89289 invoked by uid 500); 2 Apr 2007 03:09:29 -0000 Mailing-List: contact michaelbecker@example.org; run by ezmlm Precedence: bulk list-help: <mailto:michaelbecker@example.org> list-unsubscribe: <mailto:michaelbecker@example.org> List-Post: <mailto:michaelbecker@example.org> Reply-To: "Derby Development" <michaelbecker@example.org> List-Id: <derby-commits.db.apache.org> Delivered-To: mailing list michaelbecker@example.org Received: (qmail 89278 invoked by uid 99); 2 Apr 2007 03:09:29 -0000 Received: from herse.apache.org (HELO herse.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 01 Apr 2007 20:09:29 -0700 X-ASF-Spam-Status: No, hits=-100.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [83.161.120.155] (HELO eos.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 01 Apr 2007 20:09:21 -0700 Received: from eos.apache.org (localhost [83.161.120.155]) by eos.apache.org (Postfix) with ESMTP id 4D05959A07 for <michaelbecker@example.org>; Mon, 2 Apr 2007 03:09:01 +0000 (GMT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: Apache Wiki <michaelbecker@example.org> To: michaelbecker@example.org Date: Mon, 02 Apr 2007 03:09:01 -0000 Message-ID: <michaelbecker@example.org> Subject: [Db-derby Wiki] Update of "BuiltInLanguageBasedOrderingDERBY-1478" by MamtaSatoor X-Virus-Checked: Checked by ClamAV on apache.org 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 ------------------------------------------------------------------------------ 12)And last but not least, the collation methods will follow the rules defined by SQL spec in Section 9.13 Collation determination Syntax Rules 2 and 3e. In other words, at least one operand shall have a declared type collation (that means if the comparison is sysChar1|userChar1 > sysChar2|userChar2, then such a comparison will fail because both sides of > operator have collation derivation of none after applying the rules of 10 above) AND every operand whose collation derivation is implicit shall have the same declared type collation (that means if the comparison is sysChar1 > userChar1WithTerritoryBasedCollation, then such a comparison will fail because left operand has collation derivation as implicit and collation type as UCS_BASIC and the right operand has collation derivation implicit and collation type as TERRITORY_BASED) == Outstanding items == + Language changes + 1)The type definition of a data type is described by DTD (DataTypeDescriptor). This DTD will have two additional attributes called collation type and collation derivation. As per SQL spec, the collation derivation can hold 3 values, "explicit", "implicit" and "none". In Derby 10.3, the collation derivation will never be "explicit" because Derby 10.3 does not support SQL Standard's COLLATE clause. In Derby 10.3, the collation derivation can be "implicit" or "none". If collation derivation is "none", then it means the collation type can't be determined. This can happen when an aggregate function is working with operands of different collation types. If the result of such an aggregate function is character string type, then it's collation derivation will be "none", ie it can not be determined. Other than this aggregate "none" case, the collation derivation will always be "implicit" and collation type will be UCS_BASIC/TERRITORY_BASED. Which one of the 2 collation types is pick ed for a character string type is explained in section "Collation Determination". + + 2)The TypeDescriptor for character columns always has 0 for scale because scale does not apply to character datatypes. Starting Derby 10.3, this scale field in TypeDescriptor will be overloaded to indicate the collate type of the character. So, if user has requested for TERRITORY_BASED collation, then the scale in TypeDescriptor for user columns(character) will be 1(TERRITORY_BASED). The scale will be always 0(UCS_BASIC) for SYS schema character columns and for databases with collation set to UCS_BASIC. + + 3)When a character column is added using CREATE TABLE/ALTER TABLE, make sure that the correct collate type is populated in the TypeDescriptor's scale field in the SYS.SYSCOLUMNS table. + + 4)Store column level metadata for collate in Language Layer as well. This will happen in DataTypeDescriptor(DTD) with the addition of int collateType field. It will be set to 0(UCS_BASIC)/1(TERRITORY_BASED)/-1(UNKNOWN). There will be get and set methods on DTD for this new field. + + Store changes 1)Store column level metadata for collate in Store. Store keeps a version number that describes the strucutre of column level metadata. For existing pre-10.3 databases which get upgraded to 10.3 and for new 10.3 databases with default collatoin(UCS_BASIC), the structure of column level metadata will remain same as 10.2 structure of column level metadata, ie they will not include collate information in their store metadata. A new version would be used in Store for structure of column level metadata if the newly created 10.3 database has asked for territory based collation. In other words, information about collate will be kept in Store column level metadata only if we are working with a 10.3 newly created database with territory based collation. This approach will make sure that we do not have to do an on-disk store metadata upgrade when upgrading a pre-10.3 database to 10.3 version. - - 2)Store column level metadata for collate in Language Layer as well. This will happen in DataTypeDescriptor(DTD) with the addition of int collateType field. It will be set to 0(UCS_BASIC)/1(TERRITORY_BASED)/-1(UNKNOWN). There will be get and set methods on DTD for this new field. - - 3)The type definition of a data type is described by DTD (DataTypeDescriptor). This DTD will have two additional attributes called collation type and collation derivation. As per SQL spec, the collation derivation can hold 3 values, "explicit", "implicit" and "none". In Derby 10.3, the collation derivation will never be "explicit" because Derby 10.3 does not support SQL Standard's COLLATE clause. In Derby 10.3, the collation derivation can be "implicit" or "none". If collation derivation is "none", then it means the collation type can't be determined. This can happen when an aggregate function is working with operands of different collation types. If the result of such an aggregate function is character string type, then it's collation derivation will be "none", ie it can not be determined. Other than this aggregate "none" case, the collation derivation will always be "implicit" and collation type will be UCS_BASIC/TERRITORY_BASED. Which one of the 2 collation types is pick ed for a character string type is explained in section "Collation Determination". - - 4)The TypeDescriptor for character columns always has 0 for scale because scale does not apply to character datatypes. Starting Derby 10.3, this scale field in TypeDescriptor will be overloaded to indicate the collate type of the character. So, if user has requested for TERRITORY_BASED collation, then the scale in TypeDescriptor for user columns(character) will be 1(TERRITORY_BASED). The scale will be always 0(UCS_BASIC) for SYS schema character columns and for databases with collation set to UCS_BASIC. - - 5)When a character column is added using CREATE TABLE/ALTER TABLE, make sure that the correct collate type is populated in the TypeDescriptor's scale field in the SYS.SYSCOLUMNS table. - - 6)For both a newly created 10.3 database and an upgraded 10.3 database, make sure that the scale for character datatypes continue to be 0 (rather than the collation type value) through the metadata. The overloading of scale in TypeDescriptor as collation for character datatypes should be transparent to the end user. We should include test for the scale of character datatype. 7)Currently, store uses Monitor to create DVD template rows. The logic of creating DVDs using formatids should be factored out from Monitor into DataValueFactory. Talking in terms of code, RowUtil.newClassInfoTemplate should call DVF.classFromIdentifier rather than Monitor.classFromIdentifier. @@ -86, +86 @@ 11)CollatorSQLChar has a method called getCollationElementsForString which currently gets called by like method. getCollationElementsForString gets the collation elements for the value of CollatorSQLChar class. But say like method is looking for pattern 'A%' and the value of CollatorSQLChar is 'BXXXXXXXXXXXXXXXXXXXXXXX'. This is eg of one case where it would have been better to get collation element one character of CollatorSQLChar value at a time so we don't go through the process of getting collation elements for the entire string when we don't really need. This is a performance issue and could be taken up at the end of the implementation. Comments on this from Dan and Dag can be found in DERBY-2416. 12)Add tests for this feature. This a broad umbrella task but I do want to mention 3 specific tests that we should be testing - a)Make sure the scale of the character datatypes is always 0 and it didn't get impacted negatively by the overloading of scale field as collation type in TypeDescriptor. + + a)For both a newly created 10.3 database and an upgraded 10.3 database, make sure that metadata continues to show the scale for character datatypes as 0 (rather than the collation type value). That is, test that the scale of the character datatypes is always 0 and it didn't get impacted negatively by the overloading of scale field as collation type in TypeDescriptor. + b)Test case for recovery - have an outstanding transaction with insert/delete/updates that affect one or more character indexes (all with a collation setting that is different from default collation). Make sure those log records get to the log and then crash the server. Restarting the server will then run through the recovery code and will ensure that we test for correct collation usage at recovery time. Mike has put more info about this in DERBY-2336. + c)CREATE VIEW should have collation type UCS_BASIC/TERRIOTRY_BASED assocatied with it's character columns. The exact collation will be determined by what is the value of the COLLATION attribute. This is same as what would happen for CREATE TABLE. Have a test for global temporary tables with character colums too. 13)Make sure the space padding at the end of various character datatypes is implemented commented correctly in javadocs. This padding is used in collation related methods. For eg check SQLChar.stringCompare method. From derby-commitsmichaelbecker@example.org Mon Apr 02 03:12:01 2007 Return-Path: <derby-commitsmichaelbecker@example.org> Delivered-To: michaelbecker@example.org Received: (qmail 32957 invoked from network); 2 Apr 2007 03:12:00 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 2 Apr 2007 03:12:00 -0000 Received: (qmail 91429 invoked by uid 500); 2 Apr 2007 03:12:08 -0000 Delivered-To: michaelbecker@example.org Received: (qmail 91365 invoked by uid 500); 2 Apr 2007 03:12:08 -0000 Mailing-List: contact michaelbecker@example.org; run by ezmlm Precedence: bulk list-help: <mailto:michaelbecker@example.org> list-unsubscribe: <mailto:michaelbecker@example.org> List-Post: <mailto:michaelbecker@example.org> Reply-To: "Derby Development" <michaelbecker@example.org> List-Id: <derby-commits.db.apache.org> Delivered-To: mailing list michaelbecker@example.org Received: (qmail 91354 invoked by uid 99); 2 Apr 2007 03:12:08 -0000 Received: from herse.apache.org (HELO herse.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 01 Apr 2007 20:12:08 -0700 X-ASF-Spam-Status: No, hits=-100.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [83.161.120.155] (HELO eos.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 01 Apr 2007 20:11:59 -0700 Received: from eos.apache.org (localhost [83.161.120.155]) by eos.apache.org (Postfix) with ESMTP id CC96C59A07 for <michaelbecker@example.org>; Mon, 2 Apr 2007 03:11:39 +0000 (GMT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: Apache Wiki <michaelbecker@example.org> To: michaelbecker@example.org Date: Mon, 02 Apr 2007 03:11:39 -0000 Message-ID: <michaelbecker@example.org> Subject: [Db-derby Wiki] Update of "BuiltInLanguageBasedOrderingDERBY-1478" by MamtaSatoor X-Virus-Checked: Checked by ClamAV on apache.org 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 ------------------------------------------------------------------------------ == Outstanding items == Language changes + 1)The type definition of a data type is described by DTD (DataTypeDescriptor). This DTD will have two additional attributes called collation type and collation derivation. As per SQL spec, the collation derivation can hold 3 values, "explicit", "implicit" and "none". In Derby 10.3, the collation derivation will never be "explicit" because Derby 10.3 does not support SQL Standard's COLLATE clause. In Derby 10.3, the collation derivation can be "implicit" or "none". If collation derivation is "none", then it means the collation type can't be determined. This can happen when an aggregate function is working with operands of different collation types. If the result of such an aggregate function is character string type, then it's collation derivation will be "none", ie it can not be determined. Other than this aggregate "none" case, the collation derivation will always be "implicit" and collation type will be UCS_BASIC/TERRITORY_BASED. Which one of the 2 collation types is pick ed for a character string type is explained in section "Collation Determination". 2)The TypeDescriptor for character columns always has 0 for scale because scale does not apply to character datatypes. Starting Derby 10.3, this scale field in TypeDescriptor will be overloaded to indicate the collate type of the character. So, if user has requested for TERRITORY_BASED collation, then the scale in TypeDescriptor for user columns(character) will be 1(TERRITORY_BASED). The scale will be always 0(UCS_BASIC) for SYS schema character columns and for databases with collation set to UCS_BASIC. @@ -72, +73 @@ 4)Store column level metadata for collate in Language Layer as well. This will happen in DataTypeDescriptor(DTD) with the addition of int collateType field. It will be set to 0(UCS_BASIC)/1(TERRITORY_BASED)/-1(UNKNOWN). There will be get and set methods on DTD for this new field. + 5)WorkHorseForCollatorDatatypes should override all the collation related methods so that it uses the non-default Collator. All the non-default-collation-sensitive classes have an instance of WorkHorseForCollatorDatatypes which is used to call the collation related methods. This ensures that these collation related methods are implemented in one central place rather than in all the collation-sensitive classes. + + Store changes + 1)Store column level metadata for collate in Store. Store keeps a version number that describes the strucutre of column level metadata. For existing pre-10.3 databases which get upgraded to 10.3 and for new 10.3 databases with default collatoin(UCS_BASIC), the structure of column level metadata will remain same as 10.2 structure of column level metadata, ie they will not include collate information in their store metadata. A new version would be used in Store for structure of column level metadata if the newly created 10.3 database has asked for territory based collation. In other words, information about collate will be kept in Store column level metadata only if we are working with a 10.3 newly created database with territory based collation. This approach will make sure that we do not have to do an on-disk store metadata upgrade when upgrading a pre-10.3 database to 10.3 version. - 7)Currently, store uses Monitor to create DVD template rows. The logic of creating DVDs using formatids should be factored out from Monitor into DataValueFactory. Talking in terms of code, RowUtil.newClassInfoTemplate should call DVF.classFromIdentifier rather than Monitor.classFromIdentifier. + 2)Currently, store uses Monitor to create DVD template rows. The logic of creating DVDs using formatids should be factored out from Monitor into DataValueFactory. Talking in terms of code, RowUtil.newClassInfoTemplate should call DVF.classFromIdentifier rather than Monitor.classFromIdentifier. - 8)This item is related to item 10. With Derby 10.3, collation type will be the additional metadata in store for each column. When store will call DVF to create DVD template row, it will pass the formatids and the collation types. DVF will need to be able to assoicate the correct Collator with the DVD for Char datatypes depending on the collation type. And in order to find the correct Collator, DVF needs to know the locale of the database. This locale information will be set on DVF using a new method on DVF called void setLocale(Locale). This call will be made by BasicDatabase after DVF has finished booting and before store starts booting. + 3)This item is related to item 2. With Derby 10.3, collation type will be the additional metadata in store for each column. When store will call DVF to create DVD template row, it will pass the formatids and the collation types. DVF will need to be able to assoicate the correct Collator with the DVD for Char datatypes depending on the collation type. And in order to find the correct Collator, DVF needs to know the locale of the database. This locale information will be set on DVF using a new method on DVF called void setLocale(Locale). This call will be made by BasicDatabase after DVF has finished booting and before store starts booting. - 9)This item is related to item 11. When DVF gets called by store to create right DVD for given formatid and collation type, for formatids associated with character datatypes, it will first create the base character datatype class which is say SQLChar. Then it will call getValue method on the DVD with the RuleBasedCollator corresponding to the collation type as the parameter. (This RuleBasedCollator will be null for UCS_BASIC collation). The getValue method will return SQLChar or CollatorSQLChar depending on whether RuleBasedCollator is null or not. getValue is the new method which needs to be added to the interface StringDataValue. + 4)This item is related to item 3. When DVF gets called by store to create right DVD for given formatid and collation type, for formatids associated with character datatypes, it will first create the base character datatype class which is say SQLChar. Then it will call getValue method on the DVD with the RuleBasedCollator corresponding to the collation type as the parameter. (This RuleBasedCollator will be null for UCS_BASIC collation). The getValue method will return SQLChar or CollatorSQLChar depending on whether RuleBasedCollator is null or not. getValue is the new method which needs to be added to the interface StringDataValue. - 10)WorkHorseForCollatorDatatypes should override all the collation related methods so that it uses the non-default Collator. All the non-default-collation-sensitive classes have an instance of WorkHorseForCollatorDatatypes which is used to call the collation related methods. This ensures that these collation related methods are implemented in one central place rather than in all the collation-sensitive classes. + Performance items - 11)CollatorSQLChar has a method called getCollationElementsForString which currently gets called by like method. getCollationElementsForString gets the collation elements for the value of CollatorSQLChar class. But say like method is looking for pattern 'A%' and the value of CollatorSQLChar is 'BXXXXXXXXXXXXXXXXXXXXXXX'. This is eg of one case where it would have been better to get collation element one character of CollatorSQLChar value at a time so we don't go through the process of getting collation elements for the entire string when we don't really need. This is a performance issue and could be taken up at the end of the implementation. Comments on this from Dan and Dag can be found in DERBY-2416. + 1)CollatorSQLChar has a method called getCollationElementsForString which currently gets called by like method. getCollationElementsForString gets the collation elements for the value of CollatorSQLChar class. But say like method is looking for pattern 'A%' and the value of CollatorSQLChar is 'BXXXXXXXXXXXXXXXXXXXXXXX'. This is eg of one case where it would have been better to get collation element one character of CollatorSQLChar value at a time so we don't go through the process of getting collation elements for the entire string when we don't really need. This is a performance issue and could be taken up at the end of the implementation. Comments on this from Dan and Dag can be found in DERBY-2416. 12)Add tests for this feature. This a broad umbrella task but I do want to mention 3 specific tests that we should be testing From derby-commitsmichaelbecker@example.org Mon Apr 02 03:26:09 2007 Return-Path: <derby-commitsmichaelbecker@example.org> Delivered-To: michaelbecker@example.org Received: (qmail 33885 invoked from network); 2 Apr 2007 03:26:08 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 2 Apr 2007 03:26:08 -0000 Received: (qmail 1598 invoked by uid 500); 2 Apr 2007 03:26:15 -0000 Delivered-To: michaelbecker@example.org Received: (qmail 1567 invoked by uid 500); 2 Apr 2007 03:26:15 -0000 Mailing-List: contact michaelbecker@example.org; run by ezmlm Precedence: bulk list-help: <mailto:michaelbecker@example.org> list-unsubscribe: <mailto:michaelbecker@example.org> List-Post: <mailto:michaelbecker@example.org> Reply-To: "Derby Development" <michaelbecker@example.org> List-Id: <derby-commits.db.apache.org> Delivered-To: mailing list michaelbecker@example.org Received: (qmail 1556 invoked by uid 99); 2 Apr 2007 03:26:15 -0000 Received: from herse.apache.org (HELO herse.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 01 Apr 2007 20:26:15 -0700 X-ASF-Spam-Status: No, hits=-100.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [83.161.120.155] (HELO eos.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 01 Apr 2007 20:26:07 -0700 Received: from eos.apache.org (localhost [83.161.120.155]) by eos.apache.org (Postfix) with ESMTP id A283A59A07 for <michaelbecker@example.org>; Mon, 2 Apr 2007 03:25:47 +0000 (GMT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: Apache Wiki <michaelbecker@example.org> To: michaelbecker@example.org Date: Mon, 02 Apr 2007 03:25:47 -0000 Message-ID: <michaelbecker@example.org> Subject: [Db-derby Wiki] Update of "BuiltInLanguageBasedOrderingDERBY-1478" by MamtaSatoor X-Virus-Checked: Checked by ClamAV on apache.org 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 ------------------------------------------------------------------------------ 5)WorkHorseForCollatorDatatypes should override all the collation related methods so that it uses the non-default Collator. All the non-default-collation-sensitive classes have an instance of WorkHorseForCollatorDatatypes which is used to call the collation related methods. This ensures that these collation related methods are implemented in one central place rather than in all the collation-sensitive classes. + 6)At compile time, make sure that the correct character class (ex SQLChar vs CollatorSQLChar) is generated so at run time, we do not need to check what kind of Collator object need to be used for character types. It should be all handled correctly at the code generation time and the appropriate runtime methods (ex like method in SQLChar vs like method in WorkHorseForCollatorDatatypes) should get called. This is the biggest unknown to me at this point and I need to do more research. Will appreicate very much if someone has some thoughts on this. Store changes @@ -90, +91 @@ 1)CollatorSQLChar has a method called getCollationElementsForString which currently gets called by like method. getCollationElementsForString gets the collation elements for the value of CollatorSQLChar class. But say like method is looking for pattern 'A%' and the value of CollatorSQLChar is 'BXXXXXXXXXXXXXXXXXXXXXXX'. This is eg of one case where it would have been better to get collation element one character of CollatorSQLChar value at a time so we don't go through the process of getting collation elements for the entire string when we don't really need. This is a performance issue and could be taken up at the end of the implementation. Comments on this from Dan and Dag can be found in DERBY-2416. + Testing + - 12)Add tests for this feature. This a broad umbrella task but I do want to mention 3 specific tests that we should be testing + 1)Add tests for this feature. This a broad umbrella task but I do want to mention 3 specific tests that we should be testing a)For both a newly created 10.3 database and an upgraded 10.3 database, make sure that metadata continues to show the scale for character datatypes as 0 (rather than the collation type value). That is, test that the scale of the character datatypes is always 0 and it didn't get impacted negatively by the overloading of scale field as collation type in TypeDescriptor. @@ -98, +101 @@ c)CREATE VIEW should have collation type UCS_BASIC/TERRIOTRY_BASED assocatied with it's character columns. The exact collation will be determined by what is the value of the COLLATION attribute. This is same as what would happen for CREATE TABLE. Have a test for global temporary tables with character colums too. + Miscellaneous item - 13)Make sure the space padding at the end of various character datatypes is implemented commented correctly in javadocs. This padding is used in collation related methods. For eg check SQLChar.stringCompare method. + 1)Make sure the space padding at the end of various character datatypes is implemented commented correctly in javadocs. This padding is used in collation related methods. For eg check SQLChar.stringCompare method. == Implemented items == 1)Subclasses with non-default-collation have been implemented for character types SQLChar, SQLVarchar, SQLLongvarchar and SQLClob. The new subcalsses are called CollatorSQLChar, CollatorSQLVarchar, CollatorSQLLongvarchar and CollatorSQLClob, respectively. They reside in derby.iapi.types package. This work was done by revisions 516864, 516869 and 518479, 524545. From derby-commitsmichaelbecker@example.org Mon Apr 02 14:40:19 2007 Return-Path: <derby-commitsmichaelbecker@example.org> Delivered-To: michaelbecker@example.org Received: (qmail 41970 invoked from network); 2 Apr 2007 14:40:19 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 2 Apr 2007 14:40:19 -0000 Received: (qmail 37968 invoked by uid 500); 2 Apr 2007 14:40:25 -0000 Delivered-To: michaelbecker@example.org Received: (qmail 37939 invoked by uid 500); 2 Apr 2007 14:40:25 -0000 Mailing-List: contact michaelbecker@example.org; run by ezmlm Precedence: bulk list-help: <mailto:michaelbecker@example.org> list-unsubscribe: <mailto:michaelbecker@example.org> List-Post: <mailto:michaelbecker@example.org> Reply-To: "Derby Development" <michaelbecker@example.org> List-Id: <derby-commits.db.apache.org> Delivered-To: mailing list michaelbecker@example.org Received: (qmail 37928 invoked by uid 99); 2 Apr 2007 14:40:25 -0000 Received: from herse.apache.org (HELO herse.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 Apr 2007 07:40:25 -0700 X-ASF-Spam-Status: No, hits=-100.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [83.161.120.155] (HELO eos.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 Apr 2007 07:40:17 -0700 Received: from eos.apache.org (localhost [83.161.120.155]) by eos.apache.org (Postfix) with ESMTP id A627059A07 for <michaelbecker@example.org>; Mon, 2 Apr 2007 14:39:56 +0000 (GMT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: Apache Wiki <michaelbecker@example.org> To: michaelbecker@example.org Date: Mon, 02 Apr 2007 14:39:56 -0000 Message-ID: <michaelbecker@example.org> Subject: [Db-derby Wiki] Update of "BuiltInLanguageBasedOrderingDERBY-1478" by MamtaSatoor X-Virus-Checked: Checked by ClamAV on apache.org 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 ------------------------------------------------------------------------------ c)CREATE VIEW should have collation type UCS_BASIC/TERRIOTRY_BASED assocatied with it's character columns. The exact collation will be determined by what is the value of the COLLATION attribute. This is same as what would happen for CREATE TABLE. Have a test for global temporary tables with character colums too. + Metadata query changes + 1)Fix the metadata queries so that string literals can be compared with character columns from system schema. String literals will have the USER character set associated with them and system character columns will have SQL_IDENTIFIER associated with them. In order to compare them, both the sides of the comparison should come from same character set. Following casting of string literal will achieve that. syscharcol = CAST(string_literal as varchar(128)). + Miscellaneous item 1)Make sure the space padding at the end of various character datatypes is implemented commented correctly in javadocs. This padding is used in collation related methods. For eg check SQLChar.stringCompare method. From derby-commitsmichaelbecker@example.org Mon Apr 02 18:35:14 2007 Return-Path: <derby-commitsmichaelbecker@example.org> Delivered-To: michaelbecker@example.org Received: (qmail 48698 invoked from network); 2 Apr 2007 18:35:13 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 2 Apr 2007 18:35:13 -0000 Received: (qmail 64811 invoked by uid 500); 2 Apr 2007 18:35:21 -0000 Delivered-To: michaelbecker@example.org Received: (qmail 64794 invoked by uid 500); 2 Apr 2007 18:35:20 -0000 Mailing-List: contact michaelbecker@example.org; run by ezmlm Precedence: bulk list-help: <mailto:michaelbecker@example.org> list-unsubscribe: <mailto:michaelbecker@example.org> List-Post: <mailto:michaelbecker@example.org> Reply-To: "Derby Development" <michaelbecker@example.org> List-Id: <derby-commits.db.apache.org> Delivered-To: mailing list michaelbecker@example.org Received: (qmail 64783 invoked by uid 99); 2 Apr 2007 18:35:20 -0000 Received: from herse.apache.org (HELO herse.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 Apr 2007 11:35:20 -0700 X-ASF-Spam-Status: No, hits=-100.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [83.161.120.155] (HELO eos.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 Apr 2007 11:35:13 -0700 Received: from eos.apache.org (localhost [83.161.120.155]) by eos.apache.org (Postfix) with ESMTP id ECA4E59A07 for <michaelbecker@example.org>; Mon, 2 Apr 2007 18:34:52 +0000 (GMT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: Apache Wiki <michaelbecker@example.org> To: michaelbecker@example.org Date: Mon, 02 Apr 2007 18:34:52 -0000 Message-ID: <michaelbecker@example.org> Subject: [Db-derby Wiki] Update of "DerbyPronunciation" by TodmundCole X-Virus-Checked: Checked by ClamAV on apache.org 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 TodmundCole: http://wiki.apache.org/db-derby/DerbyPronunciation ------------------------------------------------------------------------------ || Jean Anderson || United States || Midwest (Minnesota) || attachment:jta_derby.wav || || Brian Bonner || United States || Northeast (Endicott, NY) || attachment:bkb_derby.wav || || Tomohito Nakayama || Japan || Central (Aichi-ken) || attachment:tmnk_derby.wav || + || Todmund Cole || United States || Southwest (Los Angeles) || attachment:cal_derby.wav || From derby-commitsmichaelbecker@example.org Mon Apr 02 18:42:57 2007 Return-Path: <derby-commitsmichaelbecker@example.org> Delivered-To: michaelbecker@example.org Received: (qmail 50551 invoked from network); 2 Apr 2007 18:42:54 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 2 Apr 2007 18:42:54 -0000 Received: (qmail 78457 invoked by uid 500); 2 Apr 2007 18:43:02 -0000 Delivered-To: michaelbecker@example.org Received: (qmail 78430 invoked by uid 500); 2 Apr 2007 18:43:01 -0000 Mailing-List: contact michaelbecker@example.org; run by ezmlm Precedence: bulk list-help: <mailto:michaelbecker@example.org> list-unsubscribe: <mailto:michaelbecker@example.org> List-Post: <mailto:michaelbecker@example.org> Reply-To: "Derby Development" <michaelbecker@example.org> List-Id: <derby-commits.db.apache.org> Delivered-To: mailing list michaelbecker@example.org Received: (qmail 78419 invoked by uid 99); 2 Apr 2007 18:43:01 -0000 Received: from herse.apache.org (HELO herse.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 Apr 2007 11:43:01 -0700 X-ASF-Spam-Status: No, hits=-100.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [83.161.120.155] (HELO eos.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 Apr 2007 11:42:54 -0700 Received: from eos.apache.org (localhost [83.161.120.155]) by eos.apache.org (Postfix) with ESMTP id 0B1DB59A07 for <michaelbecker@example.org>; Mon, 2 Apr 2007 18:42:34 +0000 (GMT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: Apache Wiki <michaelbecker@example.org> To: michaelbecker@example.org Date: Mon, 02 Apr 2007 18:42:33 -0000 Message-ID: <michaelbecker@example.org> Subject: [Db-derby Wiki] Update of "DerbyPronunciation" by TodmundCole X-Virus-Checked: Checked by ClamAV on apache.org 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 TodmundCole: http://wiki.apache.org/db-derby/DerbyPronunciation ------------------------------------------------------------------------------ || Jean Anderson || United States || Midwest (Minnesota) || attachment:jta_derby.wav || || Brian Bonner || United States || Northeast (Endicott, NY) || attachment:bkb_derby.wav || || Tomohito Nakayama || Japan || Central (Aichi-ken) || attachment:tmnk_derby.wav || - || Todmund Cole || United States || Southwest (Los Angeles) || attachment:cal_derby.wav || + || Todmund Cole || United States || Southwest (Los Angeles) || || From derby-commitsmichaelbecker@example.org Mon Apr 02 18:43:26 2007 Return-Path: <derby-commitsmichaelbecker@example.org> Delivered-To: michaelbecker@example.org Received: (qmail 50774 invoked from network); 2 Apr 2007 18:43:26 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 2 Apr 2007 18:43:26 -0000 Received: (qmail 79147 invoked by uid 500); 2 Apr 2007 18:43:33 -0000 Delivered-To: michaelbecker@example.org Received: (qmail 79119 invoked by uid 500); 2 Apr 2007 18:43:33 -0000 Mailing-List: contact michaelbecker@example.org; run by ezmlm Precedence: bulk list-help: <mailto:michaelbecker@example.org> list-unsubscribe: <mailto:michaelbecker@example.org> List-Post: <mailto:michaelbecker@example.org> Reply-To: "Derby Development" <michaelbecker@example.org> List-Id: <derby-commits.db.apache.org> Delivered-To: mailing list michaelbecker@example.org Received: (qmail 79108 invoked by uid 99); 2 Apr 2007 18:43:33 -0000 Received: from herse.apache.org (HELO herse.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 Apr 2007 11:43:33 -0700 X-ASF-Spam-Status: No, hits=-100.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [83.161.120.155] (HELO eos.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 Apr 2007 11:43:25 -0700 Received: from eos.apache.org (localhost [83.161.120.155]) by eos.apache.org (Postfix) with ESMTP id 87BB559A07 for <michaelbecker@example.org>; Mon, 2 Apr 2007 18:43:05 +0000 (GMT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: Apache Wiki <michaelbecker@example.org> To: michaelbecker@example.org Date: Mon, 02 Apr 2007 18:43:05 -0000 Message-ID: <michaelbecker@example.org> Subject: [Db-derby Wiki] Update of "DerbyPronunciation" by TodmundCole X-Virus-Checked: Checked by ClamAV on apache.org 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 TodmundCole: http://wiki.apache.org/db-derby/DerbyPronunciation ------------------------------------------------------------------------------ || Jean Anderson || United States || Midwest (Minnesota) || attachment:jta_derby.wav || || Brian Bonner || United States || Northeast (Endicott, NY) || attachment:bkb_derby.wav || || Tomohito Nakayama || Japan || Central (Aichi-ken) || attachment:tmnk_derby.wav || - || Todmund Cole || United States || Southwest (Los Angeles) || || + || Todmund Cole || United States || Southwest (Los Angeles) || attachment:cal_derby.wav || From derby-commitsmichaelbecker@example.org Mon Apr 02 19:11:03 2007 Return-Path: <derby-commitsmichaelbecker@example.org> Delivered-To: michaelbecker@example.org Received: (qmail 61128 invoked from network); 2 Apr 2007 19:11:03 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 2 Apr 2007 19:11:03 -0000 Received: (qmail 23388 invoked by uid 500); 2 Apr 2007 19:11:10 -0000 Delivered-To: michaelbecker@example.org Received: (qmail 23359 invoked by uid 500); 2 Apr 2007 19:11:10 -0000 Mailing-List: contact michaelbecker@example.org; run by ezmlm Precedence: bulk list-help: <mailto:michaelbecker@example.org> list-unsubscribe: <mailto:michaelbecker@example.org> List-Post: <mailto:michaelbecker@example.org> Reply-To: "Derby Development" <michaelbecker@example.org> List-Id: <derby-commits.db.apache.org> Delivered-To: mailing list michaelbecker@example.org Received: (qmail 23347 invoked by uid 99); 2 Apr 2007 19:11:10 -0000 Received: from herse.apache.org (HELO herse.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 Apr 2007 12:11:10 -0700 X-ASF-Spam-Status: No, hits=-100.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [83.161.120.155] (HELO eos.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 Apr 2007 12:11:02 -0700 Received: from eos.apache.org (localhost [83.161.120.155]) by eos.apache.org (Postfix) with ESMTP id 0D1F559A07 for <michaelbecker@example.org>; Mon, 2 Apr 2007 19:10:42 +0000 (GMT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: Apache Wiki <michaelbecker@example.org> To: michaelbecker@example.org Date: Mon, 02 Apr 2007 19:10:41 -0000 Message-ID: <michaelbecker@example.org> Subject: [Db-derby Wiki] Update of "BuiltInLanguageBasedOrderingDERBY-1478" by MamtaSatoor X-Virus-Checked: Checked by ClamAV on apache.org 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 ------------------------------------------------------------------------------ 1)The type definition of a data type is described by DTD (DataTypeDescriptor). This DTD will have two additional attributes called collation type and collation derivation. As per SQL spec, the collation derivation can hold 3 values, "explicit", "implicit" and "none". In Derby 10.3, the collation derivation will never be "explicit" because Derby 10.3 does not support SQL Standard's COLLATE clause. In Derby 10.3, the collation derivation can be "implicit" or "none". If collation derivation is "none", then it means the collation type can't be determined. This can happen when an aggregate function is working with operands of different collation types. If the result of such an aggregate function is character string type, then it's collation derivation will be "none", ie it can not be determined. Other than this aggregate "none" case, the collation derivation will always be "implicit" and collation type will be UCS_BASIC/TERRITORY_BASED. Which one of the 2 collation types is pick ed for a character string type is explained in section "Collation Determination". - 2)The TypeDescriptor for character columns always has 0 for scale because scale does not apply to character datatypes. Starting Derby 10.3, this scale field in TypeDescriptor will be overloaded to indicate the collate type of the character. So, if user has requested for TERRITORY_BASED collation, then the scale in TypeDescriptor for user columns(character) will be 1(TERRITORY_BASED). The scale will be always 0(UCS_BASIC) for SYS schema character columns and for databases with collation set to UCS_BASIC. + 2)The TypeDescriptor for character columns always has 0 for scale because scale does not apply to character datatypes. Starting Derby 10.3, this scale field in TypeDescriptor will be overloaded to indicate the collate type of the character. So, if user has requested for TERRITORY_BASED collation, then the scale in TypeDescriptor for user columns(character) will be 1(TERRITORY_BASED). The scale will be always 0(UCS_BASIC) for SYS schema character columns and for databases with collation set to UCS_BASIC. These changes will gon in readExternal and writeExternal methods of TypeDescriptor. 3)When a character column is added using CREATE TABLE/ALTER TABLE, make sure that the correct collate type is populated in the TypeDescriptor's scale field in the SYS.SYSCOLUMNS table. @@ -79, +79 @@ Store changes - 1)Store column level metadata for collate in Store. Store keeps a version number that describes the strucutre of column level metadata. For existing pre-10.3 databases which get upgraded to 10.3 and for new 10.3 databases with default collatoin(UCS_BASIC), the structure of column level metadata will remain same as 10.2 structure of column level metadata, ie they will not include collate information in their store metadata. A new version would be used in Store for structure of column level metadata if the newly created 10.3 database has asked for territory based collation. In other words, information about collate will be kept in Store column level metadata only if we are working with a 10.3 newly created database with territory based collation. This approach will make sure that we do not have to do an on-disk store metadata upgrade when upgrading a pre-10.3 database to 10.3 version. + 1)Store column level metadata for collate in Store. Store keeps a version number that describes the structure of column level metadata. For existing pre-10.3 databases which get upgraded to 10.3 and for new 10.3 databases with default collatoin(UCS_BASIC), the structure of column level metadata will remain same as 10.2 structure of column level metadata, ie they will not include collate information in their store metadata. A new version would be used in Store for structure of column level metadata if the newly created 10.3 database has asked for territory based collation. In other words, information about collate will be kept in Store column level metadata only if we are working with a 10.3 newly created database with territory based collation. This approach will make sure that we do not have to do an on-disk store metadata upgrade when upgrading a pre-10.3 database to 10.3 version. 2)Currently, store uses Monitor to create DVD template rows. The logic of creating DVDs using formatids should be factored out from Monitor into DataValueFactory. Talking in terms of code, RowUtil.newClassInfoTemplate should call DVF.classFromIdentifier rather than Monitor.classFromIdentifier. From derby-commitsmichaelbecker@example.org Mon Apr 02 19:38:54 2007 Return-Path: <derby-commitsmichaelbecker@example.org> Delivered-To: michaelbecker@example.org Received: (qmail 80450 invoked from network); 2 Apr 2007 19:38:53 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 2 Apr 2007 19:38:53 -0000 Received: (qmail 67537 invoked by uid 500); 2 Apr 2007 19:39:01 -0000 Delivered-To: michaelbecker@example.org Received: (qmail 67502 invoked by uid 500); 2 Apr 2007 19:39:00 -0000 Mailing-List: contact michaelbecker@example.org; run by ezmlm Precedence: bulk list-help: <mailto:michaelbecker@example.org> list-unsubscribe: <mailto:michaelbecker@example.org> List-Post: <mailto:michaelbecker@example.org> Reply-To: "Derby Development" <michaelbecker@example.org> List-Id: <derby-commits.db.apache.org> Delivered-To: mailing list michaelbecker@example.org Received: (qmail 67491 invoked by uid 99); 2 Apr 2007 19:39:00 -0000 Received: from herse.apache.org (HELO herse.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 Apr 2007 12:39:00 -0700 X-ASF-Spam-Status: No, hits=-100.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [83.161.120.155] (HELO eos.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 Apr 2007 12:38:53 -0700 Received: from eos.apache.org (localhost [83.161.120.155]) by eos.apache.org (Postfix) with ESMTP id D67E959A07 for <michaelbecker@example.org>; Mon, 2 Apr 2007 19:38:32 +0000 (GMT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: Apache Wiki <michaelbecker@example.org> To: michaelbecker@example.org Date: Mon, 02 Apr 2007 19:38:32 -0000 Message-ID: <michaelbecker@example.org> Subject: [Db-derby Wiki] Update of "BuiltInLanguageBasedOrderingDERBY-1478" by MamtaSatoor X-Virus-Checked: Checked by ClamAV on apache.org 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 ------------------------------------------------------------------------------ Metadata query changes 1)Fix the metadata queries so that string literals can be compared with character columns from system schema. String literals will have the USER character set associated with them and system character columns will have SQL_IDENTIFIER associated with them. In order to compare them, both the sides of the comparison should come from same character set. Following casting of string literal will achieve that. syscharcol = CAST(string_literal as varchar(128)). + Network Server + 1)At this point, I am not sure what kind of work (if any) will be involved for Network Server. + Miscellaneous item 1)Make sure the space padding at the end of various character datatypes is implemented commented correctly in javadocs. This padding is used in collation related methods. For eg check SQLChar.stringCompare method. From derby-commitsmichaelbecker@example.org Mon Apr 02 19:46:25 2007 Return-Path: <derby-commitsmichaelbecker@example.org> Delivered-To: michaelbecker@example.org Received: (qmail 84584 invoked from network); 2 Apr 2007 19:46:18 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 2 Apr 2007 19:46:18 -0000 Received: (qmail 86707 invoked by uid 500); 2 Apr 2007 19:46:25 -0000 Delivered-To: michaelbecker@example.org Received: (qmail 86675 invoked by uid 500); 2 Apr 2007 19:46:25 -0000 Mailing-List: contact michaelbecker@example.org; run by ezmlm Precedence: bulk list-help: <mailto:michaelbecker@example.org> list-unsubscribe: <mailto:michaelbecker@example.org> List-Post: <mailto:michaelbecker@example.org> Reply-To: "Derby Development" <michaelbecker@example.org> List-Id: <derby-commits.db.apache.org> Delivered-To: mailing list michaelbecker@example.org Received: (qmail 86658 invoked by uid 99); 2 Apr 2007 19:46:25 -0000 Received: from herse.apache.org (HELO herse.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 Apr 2007 12:46:25 -0700 X-ASF-Spam-Status: No, hits=-100.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [83.161.120.155] (HELO eos.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 Apr 2007 12:46:17 -0700 Received: from eos.apache.org (localhost [83.161.120.155]) by eos.apache.org (Postfix) with ESMTP id 8A4B159A07 for <michaelbecker@example.org>; Mon, 2 Apr 2007 19:45:57 +0000 (GMT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: Apache Wiki <michaelbecker@example.org> To: michaelbecker@example.org Date: Mon, 02 Apr 2007 19:45:57 -0000 Message-ID: <michaelbecker@example.org> Subject: [Db-derby Wiki] Update of "BuiltInLanguageBasedOrderingDERBY-1478" by MamtaSatoor X-Virus-Checked: Checked by ClamAV on apache.org 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 ------------------------------------------------------------------------------ == Outstanding items == Language changes - 1)The type definition of a data type is described by DTD (DataTypeDescriptor). This DTD will have two additional attributes called collation type and collation derivation. As per SQL spec, the collation derivation can hold 3 values, "explicit", "implicit" and "none". In Derby 10.3, the collation derivation will never be "explicit" because Derby 10.3 does not support SQL Standard's COLLATE clause. In Derby 10.3, the collation derivation can be "implicit" or "none". If collation derivation is "none", then it means the collation type can't be determined. This can happen when an aggregate function is working with operands of different collation types. If the result of such an aggregate function is character string type, then it's collation derivation will be "none", ie it can not be determined. Other than this aggregate "none" case, the collation derivation will always be "implicit" and collation type will be UCS_BASIC/TERRITORY_BASED. Which one of the 2 collation types is pick ed for a character string type is explained in section "Collation Determination".
{'source': 'Apache Software Foundation Public Mail Archives'}