[
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 Activation.
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.
Thanks!
-Rick
> 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: 10.6.0.0
>
> 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, 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.
