db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kathey Marsden <kmarsdende...@sbcglobal.net>
Subject Re: [jira] Commented: (DERBY-167) Inserting values in an identity column
Date Wed, 20 Apr 2005 05:38:55 GMT
TomohitoNakayama wrote:

> Hello.
> I have surveyed code and understand next informations.
> 1 DDL of "create table" executes ConstantAction of
> "org.apache.derby.impl.sql.execute.CreateTableConstantAction".
> 2 Insert/Update value to auto increment column is checked by method of
> "checkAutoincrement" called by bind method of "InsertNode" and
> "UpdateNode"
> 3 Information of Column is handled by class of
> "org.apache.derby.iapi.sql.dictionary.ColumnDescriptor".
> 4 ColumnDescriptor noted at 3 is created by class
> "org.apache.derby.impl.sql.catalog.SYSCOLUMNSRowFactory".
> Now, I am at a loss whether to start implementing solution 1 of
> DERBY-167.
> I think these are almost enough informations....
> best regards.
> /*
>         Tomohito Nakayama
>         tomoihto@rose.zero.ad.jp
>         tomonaka@basil.ocn.ne.jp
>         Naka
>         http://www5.ocn.ne.jp/~tomohito/TopPage.html
> */

I think these are all good pieces to the puzzle especially in
combination with your earlier posts.  There is also work in
sqlgrammar.jj for the parser and upgrade work (see below).

In your last post you  talked about adding a column to the SYSCOLUMNS
system table
+protected static final int  SYSCOLUMNS_AUTOINCREMENTRESTRICTED= 10;  

I had a few  thoughts on this.

1) Perhaps AUTOINCREMENTALWAYS would be a clearer name.

2) There would be an upgrade impact.  Changes to the system tables have
to be handled in the upgrade code
The generic code for upgrade is in
I know Dan is working on implementing the upgrade framework for this
release.  I think that is a prerequisite for the upgrade work but am not
sure.  I suppose this task  is more complex than I thought # : o

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?

>> Now, I am at a loss whether to start implementing solution 1 of
>> DERBY-167.
>> I think these are almost enough informations....
I wanted to try to understand what you mean by "at a loss".     

Are you wondering if you have enough information to start thinking of an
implementation for BY DEFAULT?
If so I would say yes.

Are you  considering whether you want to  implement BY DEFAULT (which is
perhaps more complex than I originally indicated)?
Of course this is entirely up to you.  I have been dealing with
migration issues lately so have been suggesting this heavily but don't 
let me pressure you. There are certainly other items that you could
implement where you could leverage what you have learned and if someone
else were to pick it up I am sure they would benifit from what you have
shared with us.

Are you considering whether BY DEFAULT is a good solution?
It certainly is a solution, we haven't heard any opposition from the
list, it is in the standard,  and I think it would be a welcome addition
even as other options are implemented.    I haven't researched the other

 You may already be aware of this but IBM has translated Cloudscape 
(Derby v10) manuals in Japanese.  For example the reference manual is at:
This manual has an overview of the System tables,

The page said the price was USD 66.95 but then let me http download the
pdf with no trouble.

Andrew pointed me to the IBM Publications Center:
search for Japanese Cloudscape


View raw message