[
https://issues.apache.org/jira/browse/DERBY-712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12742007#action_12742007
]
Rick Hillegas commented on DERBY-712:
-------------------------------------
Hi Suran,
Thanks for the create_drop patch. Looks like good progress. I have a couple
comments:
1) I see from your "drop sequence" stack trace that you are dealing with the
Derby type system now. There should be only one type system, but by now Derby
has at least four type systems. The root of the problem is that the original
Cloudscape type system muddled the distinction between data types and data
values. The other type systems then developed organically in order to
compensate for that original design problem. What you want to do is to follow
the example of the other datatype code in the catalogs, viz., the datatype
column in SYSCOLUMNS. You need to borrow the datatype translation code from
SYSCOLUMNS.buildDescriptor(). Replace the exception-raising line in
SYSSEQUENCESRowFactory.buildDescriptor() with the following code:
TypeDescriptor catalogType = (TypeDescriptor)
row.getColumn(SYSSEQUENCES_SEQUENCEDATATYPE).getObject();
DataTypeDescriptor dataType =
DataTypeDescriptor.getType(catalogType);
The explanation for why you do this is offered by the comment around the
corresponding coercion logic in SYSCOLUMNSRowFactory.buildDescriptor().
2) I think that the missing sequence descriptor condition can be handled with
the same SQLState used by other DROP code. See, for instance, the corresponding
code in DropTriggerConstantAction. You would write something like this:
throw
StandardException.newException(SQLState.LANG_OBJECT_NOT_FOUND_DURING_EXECUTION,
"SEQUENCE",
(schemaName + "." + sequenceName));
3) Also, I notice that I get an assertion failure on the second CREATE
statement in this batch:
create sequence foo;
create sequence foo;
This is because you need to implement some more methods in SequenceDescriptor.
Take a look at the TupleDescriptor superclass for all methods which raise
NOTREACHED assertions if they are not overridden.
4) Your SequenceDescriptor.drop() code is a good start, but you also need to
invalidate other compiled statements which depend on the sequence which is
about to disappear. The next time one of those statements executes, this
invalidation will cause the statement to recompile, discover that the sequence
no longer exists, and fail. You need to call DependencyManager.invalidateFor().
See the drop() logic in the other tuple descriptors for examples of how to do
this.
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_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.
