db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Suran Jayathilaka (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-712) Support for sequences
Date Sun, 24 May 2009 16:53:46 GMT

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

Suran Jayathilaka commented on DERBY-712:
-----------------------------------------

Following are some questions that I asked Rick Hillegas and Rick's answers to them. Posting
here because the conversation wasn't sent to the mailing list, which I will do henceforth.
-----------------------------------------------------------------------------------------

1. Once I have the barebones classes for the SEQUENCE catalog, what's the best way to get
about testing them and fleshing them out?
A: It's usually easiest to write the test after you've done the parser changes for CREATE/DROP'ing
your schema objects. Right now, you could add an upgrade test to verify that the new catalog
is created after hard-upgrade but not after soft-upgrade. The upgrade tests live in trunk/java/testing/org/apache/derbyTesting/functionTests/tests/upgradeTests/

2. How can I define what comes in the indexColumnPositions array in the SYSSEQUENCESRowFactory?
    I currently have
    private static final int[][] indexColumnPositions =
       {
           {SYSSEQUENCES_SEQUENCEID},
           {SYSSEQUENCES_SEQUENCENAME, SYSSEQUENCES_SCHEMAID}
       };
A: That looks like a good start. That is the array which defines the number and shapes of
the indexes defined on your catalog. As you get into coding support for compilation and dependency
tracking, you may discover that you need to define some other indexes to speed up access to
the sequence descriptors. You can add more indexes later if you need them, so you don't have
to worry too much about this right now...

3. What's the use of the "uniqueness" array?
A: The array is null if ALL of the indexes on the catalog are unique indexes. If any of the
indexes is non-unique, then you need to fill in an array of booleans, one per index. The slot
in that array is true if the corresponding index is unique, and false otherwise. See for instance
SYSCOLPERMSRowFactory. Right now both of your indexes are unique so you can leave the uniqueness
array as null.

4. In StoredFormatIds, I see 2 fields for some elements like TRIGGERS
    i.e.
    /**
       class org.apache.derby.impl.sql.catalog.TriggerDescriptorFinder
        */
       static public final int TRIGGER_DESCRIPTOR_FINDER_V01_ID =   (MIN_ID_2 + 320);

       /**
       class org.apache.derby.impl.sql.catalog.TriggerDescriptorFinder
        */
       static public final int TRIGGER_DESCRIPTOR_V01_ID =  (MIN_ID_2 + 316);
   What's the difference in usage of these 2 IDs? And why is there not a class named TriggerDescriptorFinder
as mentioned in the comments here?
A: I think that at one point there was a DependableFinder for every kind of TupleDescriptor.
The DependableFinders are objects which are serialized into the DEPENDENTFINDER and PROVIDERFINDER
columns of SYSDEPENDS. When they are deserialized, they are capable of asking the data dictionary
for the correct kind of TupleDescriptors for the corresponding UUID columns in SYSDEPENDS.
This is how persistent dependencies are serialized and how they reconstruct the dependency
graph when they are read in.
At some point most of the DependableFinders were collapsed into a single class, DDdependableFinder
and some tricky (de)serialization logic was added so that the serialized form of the DependableFinders
could be as simple as possible, namely a format id corresponding to the appropriate kind of
TupleDescriptor.
Because triggers can invoke sequence generators, you will have to use SYSDEPENDS to record
persistent dependencies between triggers and sequences. So you will need to add a DependableFinder
format id as well as a format id for the SequenceDescriptor.

5. In the Authorizer class, do I need to add fields for creating/modifying/dropping sequences
and perms, or are they covered in SCHEMA privileges?
A: Creating/dropping sequences should behave like the creating/dropping of other schema objects:
If you own the schema, then you implicitly have permission to create/drop any kind of schema
object inside that schema. So no new privileges are needed just to create/drop sequences.
   To invoke a sequence, however, a new privilege is needed: USAGE.  This is like EXECUTE_PRIV
or INSERT_PRIV.

6. Where in the code do the catalog tables get created when creating a new database?
A: That happens in DataDictionaryImpl.createDictionaryTables().

7. Do I need to add entries to the C_NodeTypes class? I didn't fully understand the purpose
of this class from the javadoc comments.
A: This class was introduced in order to eliminate a large NodeFactory interface. That was
a worthy goal, but I think that as a result, node creation has been made weakly typed and
hard to follow. Each kind of node has its own corresponding node type. When you get to the
parser work, you will need to add a CreateSequenceNode, a DropSequenceNode, and a NextValue
node--each with its own node type in C_NodeTypes.



> 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
>         Attachments: 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.


Mime
View raw message