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 Wed, 12 Aug 2009 19:17:15 GMT

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

Rick Hillegas commented on DERBY-712:

Hi Suran,

As you noted, you'll need to move on to the next task after you are done with the machinery
for basic CREATE/DROP SEQUENCE. I think that the best next step would be to build the machinery
for actually using sequences in statements. I think it will be easier if you do this first
and then come back later to add the GRANT/REVOKE USAGE ON SEQUENCE machinery, which restricts
who can use a given sequence.

So I recommened starting out allowing anybody to use a NEXT VALUE FOR <sequence> right
now. At the same time, link DERBY-712 to a new JIRA for adding the GRANT/REVOKE machinery.

The semantics of the NEXT VALUE clause are:

i) It can appear in scalar expressions.

ii) It is forbidden in certain contexts (see the section in the functional spec titled "New
Syntax for Using Sequences").

You will need to make the following changes, described below. To speed up review, you may
want to chunk in these changes in this order:

A) Parser changes.

B) Binding changes.

C) Code generation changes.

D) Execution changes.

(A) Parser Changes

In the AST, I think you will want to represent NEXT VALUE FOR <sequence> with a new
NextSequenceNode, a kind of ValueNode. I think you will get into the least trouble if you
follow the ANSI grammar as closely as possible. According to part 2, section 6.3 of the ANSI
spec, a <next value expression> is one of the possibilities for a <value expression
primary>. So I would make NextSequenceNode one of the  possibilities for  valueExpressionPrimary()
in sqlgrammar.

(B) Binding Changes

When binding a NextSequenceNode, you will want to enforce the restrictions in the spec section
titled "New Syntax for Using Sequences". I think this will be easiest if you push/pop and
inspect restriction contexts using the CompilerContext.getReliability()/setReliability() machinery.
You can use the GENERATION_CLAUSE_RESTRICTION logic as a template.

(C) Code Generation and Execution Changes

Fortunately, sequences are a lot like autoincrement columns. I think you will want a SequenceCounter
object which is a lot like an AutoincrementCounter. I think it's fine to let GenericLanguageConnectionContext
manage a cache of SequenceCounters.

A big difference between sequences and autoincrement counters is this: multiple NEXT SEQUENCE
FOR <sequence> clauses in a single statement should resolve to the same value, whereas
multiple rows in a single INSERT statement will each get their own unique autoincrement value.
I think this means that you will want to cache the NEXT SEQUENCE value in the statement's

That, in turn, means that when you generate() the executable code, you will want to generate
a call to some new method on the Activation rather than directly to a method on the LanguageConnectionContext.

This is just a sketch of what makes sense to me. You will probably have a lot of questions
and after looking into the code, you may have some better ideas.


> Support for sequences
> ---------------------
>                 Key: DERBY-712
>                 URL: https://issues.apache.org/jira/browse/DERBY-712
>             Project: Derby
>          Issue Type: Improvement
>          Components: SQL
>         Environment: feature request 
>            Reporter: Tony Dahbura
>            Assignee: Suran Jayathilaka
>             Fix For:
>         Attachments: altertable.diff, catalogs_a.patch, catalogs_b.patch, catalogs_c.patch,
catalogs_d.patch, catalogs_e.patch, catalogs_f.patch, catalogs_f_2.patch, catalogs_g.diff,
catalogs_h.diff, create_drop_sequence_a.patch, create_drop_sequence_b.patch, create_sequence_a.patch,
> 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