From derby-dev-return-3379-apmail-db-derby-dev-archive=db.apache.org@db.apache.org Sat Apr 23 02:16:01 2005 Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 37112 invoked from network); 23 Apr 2005 02:16:01 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 23 Apr 2005 02:16:01 -0000 Received: (qmail 38759 invoked by uid 500); 23 Apr 2005 02:16:29 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 38714 invoked by uid 500); 23 Apr 2005 02:16:28 -0000 Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: List-Id: Reply-To: "Derby Development" Delivered-To: mailing list derby-dev@db.apache.org Received: (qmail 38700 invoked by uid 99); 23 Apr 2005 02:16:28 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: local policy) Received: from basil.ocn.ne.jp (HELO smtp.basil.ocn.ne.jp) (222.146.51.83) by apache.org (qpsmtpd/0.28) with ESMTP; Fri, 22 Apr 2005 19:16:28 -0700 Received: from [192.168.0.32] (p1210-adsah09honb5-acca.tokyo.ocn.ne.jp [218.224.7.210]) by smtp.basil.ocn.ne.jp (Postfix) with ESMTP id 059293B42 for ; Sat, 23 Apr 2005 11:15:56 +0900 (JST) Received: from 127.0.0.1 (AVG SMTP 7.0.308 [266.10.2]); Sat, 23 Apr 2005 11:17:21 +0900 Message-ID: <000c01c547aa$9486c5c0$2000a8c0@Arkat> From: "TomohitoNakayama" To: "Derby Development" References: <118869683.1112803762787.JavaMail.jira@ajax.apache.org> <002b01c54032$237bde30$2000a8c0@Arkat> <000201c543ff$81fde9f0$2000a8c0@Arkat> <4265EAEF.3070407@sbcglobal.net> <002001c545fe$6db511c0$2000a8c0@Arkat> <426720BD.7050900@debrunners.com> <003001c54679$a10d7cd0$2000a8c0@Arkat> <001101c5473e$dddba130$2000a8c0@Arkat> <000401c5474d$957ba750$2000a8c0@Arkat> Subject: Re: [jira] Commented: (DERBY-167) Inserting values in an identity column Date: Sat, 23 Apr 2005 11:17:15 +0900 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; format=flowed; charset=utf-8; reply-type=response X-Virus-Checked: Checked X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Hello. About next ... >> And furthermore , as touched upon in mail of Kathey, >> there are question in current structure of information for default value. >> >> I think autoincremented value is a kind of default value. >> But current implementation handled them separetedly. >> >> I think this structure should be cleaned up in the future. >> New task may be needed for that. I want to leave comment of point to clean up , in source code. Example: sglgrammer.jj: generatedColumnOption(long[]) /* * generatedColumnOption */ //ToCleanUp //A specific class not such long[] should exists for autoIncrementInfo ... ValueNode generatedColumnOption(long[] autoIncrementInfo) throws StandardException : { ValueNode value = null; } { { autoIncrementInfo[QueryTreeNode.AUTOINCREMENT_START_INDEX] = 1; autoIncrementInfo[QueryTreeNode.AUTOINCREMENT_INC_INDEX] = 1; autoIncrementInfo[QueryTreeNode.AUTOINCREMENT_IS_AUTOINCREMENT_INDEX] = 1; } [ value = autoIncrementBeginEnd(autoIncrementInfo) ] { return value; } } And it may be needed to leave some id in this comment to future clean up task , though it may be too complex ... Best regards. /* Tomohito Nakayama tomonaka@basil.ocn.ne.jp tomohito@rose.zero.ad.jp Naka http://www5.ocn.ne.jp/~tomohito/TopPage.html */ ----- Original Message ----- From: "TomohitoNakayama" To: "Derby Development" Sent: Saturday, April 23, 2005 12:11 AM Subject: Re: [jira] Commented: (DERBY-167) Inserting values in an identity column > Sorry mistaken. > > >> I have done additional survey of sql grammer and put in order information >> including those in previous my mails. > > I have done additional survey of sql grammer and put informations in order > including those in previous my mails. > > > Best regards. > > > /* > > Tomohito Nakayama > tomonaka@basil.ocn.ne.jp > tomohito@rose.zero.ad.jp > > Naka > http://www5.ocn.ne.jp/~tomohito/TopPage.html > > */ > ----- Original Message ----- > From: "TomohitoNakayama" > To: "Derby Development" > Sent: Friday, April 22, 2005 10:26 PM > Subject: Re: [jira] Commented: (DERBY-167) Inserting values in an identity > column > > >> Hello. >> >> >> I have done additional survey of sql grammer and put in order information >> including those in previous my mails. >> >> ========= >> Processing which concerns to this task is next three processing. >> >> 1:processing in create table sql statement >> 2:processng insert/update sql statement. >> 3:processing in upgrade >> >> >> Nexts are result of survey for implementation of those three processing. >> >> 1: >> create table statement was parsed to >> "org.apache.derby.impl.sql.compile.CreateTableNode"　instance. >> Each column was parsed by expansion of columnDefinition to >> "org.apache.derby.impl.sql.compile.ColumnDefinitionNode" instance. >> Furthermore information of autoincrement was parsed by expansion of >> generatedColumnOption to long[3] and returned via parameters of method. >> >> CreateTableNode creates >> "org.apache.derby.impl.sql.execute.CreateTableConstantAction" instance in >> makeConstantAction() method. >> >> >> 2: >> Restriction of value of auto increment column to auto incremented value >> was >> done by calling checkAutoincrement method from bind method of >> InsertNode/UpdateNode bind. >> >> In that process , information of Columns was handled by >> "org.apache.derby.iapi.sql.dictionary.ColumnDescriptor". >> And these , ColumnDescriptor , was created by >> "org.apache.derby.impl.sql.catalog.SYSCOLUMNSRowFactory" >> >> >> 3: >> Upgrade process seems to be done in >> "org.apache.derby.impl.sql.catalog.DD_Version". >> >> >> >> ========= >> >> And furthermore , as touched upon in mail of Kathey, >> there are question in current structure of information for default value. >> >> I think autoincremented value is a kind of default value. >> But current implementation handled them separetedly. >> >> I think this structure should be cleaned up in the future. >> New task may be needed for that. >> >> >> Best regards. >> >> >> /* >> >> Tomohito Nakayama >> tomonaka@basil.ocn.ne.jp >> tomohito@rose.zero.ad.jp >> >> Naka >> http://www5.ocn.ne.jp/~tomohito/TopPage.html >> >> */ >> ----- Original Message ----- >> From: "TomohitoNakayama" >> To: "Derby Development" >> Sent: Thursday, April 21, 2005 10:54 PM >> Subject: Re: [jira] Commented: (DERBY-167) Inserting values in an >> identity >> column >> >> >>> Hello. >>> >>> >>>> Upgrade is a part of any Derby release, and traditionally it has always >>>> been made very easy for the end-user, namely adding the attribute >>>> 'upgrade=true' to a connection request that boots the database. Having >>>> a >>>> feature require upgrade involves more work, but it should not affect >>>> any >>>> decision on if the feature should be implemented. Now it may be best to >>>> see how the upgrade for a feature can be minimized, e.g. using existing >>>> system table columns is less work than adding system columns. >>> >>> I found next information. >>> http://incubator.apache.org/derby/papers/versionupgrade.html >>> This seems to be corresponding. >>> >>> >>>>> I think the decision should be made not only by me ... >>>> >>>> In a way, open source projects are based on decisions made by a single >>>> person, because they actually do the work and contribute the feature. >>>> It >>>> might be best for you to say which you are willing to work on and then >>>> see if anyone objects, I can't see any objections for option 1) and you >>>> say it's the easiest for the user. >>> >>> Well ... >>> My decision is to start implementing option1. >>> And option2 and option3 are to be left for future develpment. >>> >>> I seems to be unfamiliar with the process of open source yet ... >>> Thank you for your advise! >>> >>> >>> Best regards. >>> >>> >>> /* >>> >>> Tomohito Nakayama >>> tomonaka@basil.ocn.ne.jp >>> tomohito@rose.zero.ad.jp >>> >>> Naka >>> http://www5.ocn.ne.jp/~tomohito/TopPage.html >>> >>> */ >>> ----- Original Message ----- >>> From: "Daniel John Debrunner" >>> To: "Derby Development" >>> Sent: Thursday, April 21, 2005 12:40 PM >>> Subject: Re: [jira] Commented: (DERBY-167) Inserting values in an >>> identity >>> column >>> >>> >>>> TomohitoNakayama wrote: >>>> >>>>> Hello. >>>>> >>>>> >>>>> I think the upgrade impact is very serious issue technically. >>>>> >>>>> Can you tell me more information about next ? >>>>> >>>>>> I know Dan is working on implementing the upgrade framework for this >>>>>> release. >>>> >>>> Upgrade is a part of any Derby release, and traditionally it has always >>>> been made very easy for the end-user, namely adding the attribute >>>> 'upgrade=true' to a connection request that boots the database. Having >>>> a >>>> feature require upgrade involves more work, but it should not affect >>>> any >>>> decision on if the feature should be implemented. Now it may be best to >>>> see how the upgrade for a feature can be minimized, e.g. using existing >>>> system table columns is less work than adding system columns. >>>> >>>>> About solution 1-3, I think mainteanceability should be more >>>>> discussed, >>>>> according to "http://incubator.apache.org/derby/#Easy+to+Use" >>>>> As in my previous mail, I think solution 1 is most easy to use for >>>>> user, >>>>> on the other hand , solution 2 and solution 3 will enable user to keep >>>>> their DB more proper. >>>> >>>> If you think about option 1) by itself, GENERATED BY DEFAULT, then it's >>>> in the SQL standard, and it's a useful feature. On that basis alone >>>> it's a good addition to Derby, and most likely a good medium complexity >>>> project to add to your Derby knowledge. Now just doing option 1) may >>>> not >>>> result in Derby-167 being fixed, but it is a good addition to Derby. >>>> >>>>> I think the decision should be made not only by me ... >>>> >>>> In a way, open source projects are based on decisions made by a single >>>> person, because they actually do the work and contribute the feature. >>>> It >>>> might be best for you to say which you are willing to work on and then >>>> see if anyone objects, I can't see any objections for option 1) and you >>>> say it's the easiest for the user. >>>> >>>> Thanks for getting involved in Derby! >>>> Dan. >>>> >>>> >>>> >>>> >>>> -- >>>> No virus found in this incoming message. >>>> Checked by AVG Anti-Virus. >>>> Version: 7.0.308 / Virus Database: 266.10.1 - Release Date: 2005/04/20 >>>> >>> >>> >>> >>> -- >>> No virus found in this outgoing message. >>> Checked by AVG Anti-Virus. >>> Version: 7.0.308 / Virus Database: 266.10.1 - Release Date: 2005/04/20 >>> >>> >>> >>> >>> -- >>> No virus found in this incoming message. >>> Checked by AVG Anti-Virus. >>> Version: 7.0.308 / Virus Database: 266.10.1 - Release Date: 2005/04/20 >>> >>> >> >> >> >> -- >> No virus found in this outgoing message. >> Checked by AVG Anti-Virus. >> Version: 7.0.308 / Virus Database: 266.10.2 - Release Date: 2005/04/21 >> >> >> >> >> -- >> No virus found in this incoming message. >> Checked by AVG Anti-Virus. >> Version: 7.0.308 / Virus Database: 266.10.2 - Release Date: 2005/04/21 >> >> > > > > -- > No virus found in this outgoing message. > Checked by AVG Anti-Virus. > Version: 7.0.308 / Virus Database: 266.10.2 - Release Date: 2005/04/21 > > > > > -- > No virus found in this incoming message. > Checked by AVG Anti-Virus. > Version: 7.0.308 / Virus Database: 266.10.2 - Release Date: 2005/04/21 > > -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.10.2 - Release Date: 2005/04/21