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
[EMAIL PROTECTED]
[EMAIL PROTECTED] Naka
http://www5.ocn.ne.jp/~tomohito/TopPage.html*/
----- Original Message ----- From: "TomohitoNakayama" <[EMAIL PROTECTED]>
To: "Derby Development" <[email protected]>
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 [EMAIL PROTECTED] [EMAIL PROTECTED]
Naka http://www5.ocn.ne.jp/~tomohito/TopPage.html
*/
----- Original Message ----- From: "TomohitoNakayama" <[EMAIL PROTECTED]>
To: "Derby Development" <[email protected]>
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 [EMAIL PROTECTED] [EMAIL PROTECTED]
Naka http://www5.ocn.ne.jp/~tomohito/TopPage.html
*/
----- Original Message ----- From: "TomohitoNakayama" <[EMAIL PROTECTED]>
To: "Derby Development" <[email protected]>
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 [EMAIL PROTECTED] [EMAIL PROTECTED]
Naka http://www5.ocn.ne.jp/~tomohito/TopPage.html
*/
----- Original Message ----- From: "Daniel John Debrunner" <[EMAIL PROTECTED]>
To: "Derby Development" <[email protected]>
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
