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 About clean up DefaultInfoImpl issue ... (Re: [jira] Commented: (DERBY-167) Inserting values in an identity column)
Date Sun, 24 Apr 2005 13:39:54 GMT
Hello.

Hacking in DERBY-167, I may found some idea about question by Kathy ...

Kathy wrote:
>3)  I am not really clear why we have all those separate columns for the
>autoincrement information instead of  including  them in the
>COLUMNDEFAULT column.  It is  the DefaultInfoImpl class which implements
>DefaultInfo that goes  into that column.  Currently it has only one
>method getDefaultText() which is used for static default values.  I
>don't know the history on why  the autoincrement info  broken out this
>way or whether it would be better now to add another column or somehow
>integrate BY DEFAULT into the COLUMNDEFAULT column by modifying 
>DefaultInfo.    Does anyone have any thoughts on this?

If we meke COLUMNDEFAULT  to have whole autoincrement information including 
next value of autogenerated value currently stored in IDENTITYCOLUMNVALUE,
it would result in that we need to externalize whole of  DefaultInfoImpl 
,when identity value is newly generated , though any other information was 
not changed.
To avoid it , it is needed to implement unhappy-partially-storing-trick in 
externalizing of DefaultInfoImpl .

I don't know why IDENTITYCOLUMNSTART and IDENTITYCOLUMNINC are separeted.
But I think there exists reason why IDENTITYCOLUMNVALUE is separeted.

// Now I think it is reasonable to consider DefaultInfoImpl  as definitive 
information both of default valule and autoincrement value.

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: Saturday, April 23, 2005 11:17 AM
Subject: Re: [jira] Commented: (DERBY-167) Inserting values in an identity 
column


> 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[])
>
> /*
> * <A NAME="generatedColumnOption">generatedColumnOption</A>
> */
>
> //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;
>    }
>
> <GENERATED> <ALWAYS> <AS> <IDENTITY> [<LEFT_PAREN> value
= 
> autoIncrementBeginEnd(autoIncrementInfo) <RIGHT_PAREN>]
>    {
>  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" <tomonaka@basil.ocn.ne.jp>
> To: "Derby Development" <derby-dev@db.apache.org>
> 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" <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
>>
>>
>>
>>
>> -- 
>> 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


Mime
View raw message