db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "TomohitoNakayama" <tomon...@basil.ocn.ne.jp>
Subject Re: [jira] Commented: (DERBY-167) Inserting values in an identity column
Date Fri, 22 Apr 2005 13:26:11 GMT
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


Mime
View raw message