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 Tue, 11 Aug 2009 18:38:14 GMT

    [ 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.


Mime
View raw message