db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-712) Support for sequences
Date Fri, 12 Jun 2009 14:54:07 GMT

    [ https://issues.apache.org/jira/browse/DERBY-712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12718862#action_12718862

Rick Hillegas commented on DERBY-712:

Hi Suran,

The new catalogs_b.patch looks very good. It will need another round or two of adjusting but
it is definitely looking solid. I have applied the patch and am running regression tests now.
I will post my results when the tests finish.

I have some comments on the new patch:


o You should remove the permUUID field from this class since it shadows the oid field in the
superclass. In my experience, this kind of shadowing always causes bugs in the future because
it is so easy to lose track of which copy of the redundant field is being used. So the constructor
for this class should call setUUID( permUUID ) rather than stuffing the shadowing field via
"this.permUUID = permUUID".

o Once you do that, you can get rid of the getUUID(), setUUID(), and getObjectID() methods
in this class.

o I have reservations about the second constructor for this class (the one which is used to
create a key descriptor rather than a full-fledged permissions descriptor). However, I see
that you are following the data dictionary patterns for the other permissions descriptors.
I think you are right to follow the existing patterns. But we should put a sticky note on
our brains to remind ourselves to clean up this pattern in the future--partially initialized
data is brittle. This is something we can revisit when we collapse all of the permissions
catalogs into the master catalog which you are creating. Don't worry, that's another project
and not part of the sequence generator work.


o I think that you should flip the order of the keys in the second index. That is, the key
order should be ( schemaID, sequenceName ) rather than ( sequenceName, schemaID ). This will
speed up the check in DataDictionaryImpl.isSchemaEmpty(). But maybe you have a use for an
index with key order ( sequenceName, schemaID ) which I'm not seeing. If so, then I would
recommend adding a third index. Note that if you swap the key order, then you will need to
make a corresponding change to DataDictionaryImpl.getSequenceDescriptor(String, SchemaDescriptor)

o I think that buildColumnList() should return an array of 10 column descriptors, one for
each column in the table. See, for instance, the corresponding method in SYSALIASESRowFactory.


o As with SYSSEQUENCESRowFactory, I think that buildColumnList() should return a larger array,
one cell for each column in the table.


o The header comment for getPermDescriptor() does not seem to describe the method.


o I think that you can remove the stub for dropSequenceDescriptor(String, TransactionController)
because you have removed this method from the DataDictionary interface.


o The header comments on getUncachedPermDescriptor() getPermDescriptor(), and dropAllPermDescriptors()
look like they were copied from pre-existing methods, so they should be revised to describe
the new methods.


> Support for sequences
> ---------------------
>                 Key: DERBY-712
>                 URL: https://issues.apache.org/jira/browse/DERBY-712
>             Project: Derby
>          Issue Type: New Feature
>          Components: SQL
>         Environment: feature request 
>            Reporter: Tony Dahbura
>            Assignee: Suran Jayathilaka
>             Fix For:
>         Attachments: catalogs_a.patch, catalogs_b.patch, SequenceGenerator.html
> Would like to see support added for sequences.  This would permit a select against the
sequence to always obtain a ever increasing/decreasing value.  The identity column works fine
but there are times for applications where the application needs to obtain the sequence number
and use it prior to the database write.  Subsequent calls to the table/column would result
in a new number on each call.
> SQL such as the following:
> SELECT NEXT VALUE FOR sequence_name FROM sometable ; would result in a next value.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message