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
[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 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 [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
-- 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
