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 Sat, 23 Apr 2005 02:17:15 GMT
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


Mime
View raw message