Return-Path: Delivered-To: apmail-db-derby-commits-archive@www.apache.org Received: (qmail 30812 invoked from network); 2 Apr 2007 02:58:34 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) 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: apmail-db-derby-commits-archive@db.apache.org Received: (qmail 82720 invoked by uid 500); 2 Apr 2007 02:58:41 -0000 Mailing-List: contact derby-commits-help@db.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: "Derby Development" List-Id: Delivered-To: mailing list derby-commits@db.apache.org Received: (qmail 82709 invoked by uid 99); 2 Apr 2007 02:58:41 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) 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 [140.211.11.130] (HELO eos.apache.org) (140.211.11.130) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 01 Apr 2007 19:58:33 -0700 Received: from eos.apache.org (localhost [127.0.0.1]) by eos.apache.org (Postfix) with ESMTP id 1C92F59A07 for ; 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 To: derby-commits@db.apache.org Date: Mon, 02 Apr 2007 02:58:12 -0000 Message-ID: <20070402025812.6387.17822@eos.apache.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.