Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Development" <derby-dev@db.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <000401c5474d$957ba750$2000a8c0@Arkat>
From: "TomohitoNakayama" <tomonaka@basil.ocn.ne.jp>
To: "Derby Development" <derby-dev@db.apache.org>
References: <118869683.1112803762787.JavaMail.jira@ajax.apache.org>
 <002b01c54032$237bde30$2000a8c0@Arkat>
 <d9619e4a05041311412b1a748b@mail.gmail.com>
 <d9619e4a050417133062473e1f@mail.gmail.com>
 <000201c543ff$81fde9f0$2000a8c0@Arkat> <4265EAEF.3070407@sbcglobal.net>
 <002001c545fe$6db511c0$2000a8c0@Arkat> <426720BD.7050900@debrunners.com>
 <003001c54679$a10d7cd0$2000a8c0@Arkat> <001101c5473e$dddba130$2000a8c0@Arkat>
Subject: Re: [jira] Commented: (DERBY-167) Inserting values in an identity
 column
Date: Sat, 23 Apr 2005 00:11:36 +0900
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; format=flowed; charset=utf-8; reply-type=response

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" <tomonaka@basil.ocn.ne.jp>
To: "Derby Development" <derby-dev@db.apache.org>
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" <tomonaka@basil.ocn.ne.jp>
> To: "Derby Development" <derby-dev@db.apache.org>
> 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" <djd@debrunners.com>
>> To: "Derby Development" <derby-dev@db.apache.org>
>> 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