[
https://issues.apache.org/jira/browse/PHOENIX-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14066269#comment-14066269
]
Thomas D'Silva commented on PHOENIX-1016:
-----------------------------------------
James,
I have attached a new patch with changes that will allow for upgrading existing
sequences. I had to modify CreateSequenceCompiler to handler null values for
minValue, maxValue and cycle to handle upgraded sequence rows (the values are
set to Long.MIN_VALUE, Long.MAX_VALUE and false respectively).
I tested that sequences created in 3.0 and 4.0 worked correctly when upgraded
to 3.1 and 4.1 (CACHE SIZE values will be skipped when next value is first
called). The 4.1 patch also applied cleanly to the master branch.
I had question about the default behavior for CYCLE, previously sequences would
cycle if the next value reaches Long.MIN_VALUE,/Long.MAX_VALUE (since long
would just overflow/underflow), with my changes the default behavior is to
throw an exception and not cycle. Is this OK? If I have to keep the existing
behavior, I would have to add a “NO CYCLE” option to the grammar.
I made a few changes to existing tests in SequenceIT:
testCreateSequence() - I modified the check for current_value to check for null
instead of the start value.
testCurrentValueFor() - I added an assert to check that only one SQLException
is thrown. I also assert that current_value is null instead of startValue and
modified the test to use the assertSequenceValuesForSingleRow() helper function
I added to verify that the expected sequence values are returned.
testSequenceCreation() - I added a check to see that the min_value, max_value
and cache_size are initialized correctly.
testSelectNextValueForMultipleConnWithConnClose() - calling connection.close()
doesn’t return sequences in this test, so I added a function
returnAllSequences() to ConnectionQueryServicesTestImpl and called it after
conn1.close() to actually return the sequence.
testExplainPlanValidatesSequences() - I modified the check for current_value to
check for null instead of the start value.
testSelectNextValueAsInput() - I added this test as part of my LPAD/ENCODE
changes, I modified it to use the LPAD/ENCODE functions instead of COAELESCE
Please let me know if anything else needs to be changed.
Thanks,
Thomas
> Support MINVALUE, MAXVALUE, and CYCLE options in CREATE SEQUENCE
> ----------------------------------------------------------------
>
> Key: PHOENIX-1016
> URL: https://issues.apache.org/jira/browse/PHOENIX-1016
> Project: Phoenix
> Issue Type: Bug
> Reporter: James Taylor
> Assignee: Thomas D'Silva
> Attachments: AddSeqColumns.txt, PHOENIX-1016.3.0.patch,
> PHOENIX-1016.patch, PHOENIX-1016.v2.3.0.patch, PHOENIX-1016.v2.patch, diff.txt
>
>
> We currently don't support MINVALUE, MAXVALUE, and CYCLE options in CREATE
> SEQUENCE, but we should. See
> http://msdn.microsoft.com/en-us/library/ff878091.aspx for the syntax.
> I believe MINVALUE applies if the INCREMENT is negative while MAXVALUE
> applies otherwise. If the value of a sequence goes beyond MINVALUE/MAXVALUE,
> then:
> - if CYCLE is true, then the sequence value should start again at the START
> WITH value (or the MINVALUE if specified too? Not sure about this).
> - if CYCLE is false, then an exception should be thrown.
> To implement this:
> - make the grammar changes in PhoenixSQL.g
> - add member variables for MINVALUE, MAXVALUE, and CYCLE to
> CreateSequenceStatement
> - add the appropriate error checking and handle bind variables for these new
> options in CreateSequenceCompiler
> - modify the MetaDataClient.createSequence() call by passing along these new
> parameters.
> - same for ConnectionQueryServices.createSequence() call
> - same for Sequence.createSequence().
> - pass along these parameters as new KeyValues in the Append that constitutes
> the RPC call
> - act on these in the SequenceRegionObserver coprocessor as indicated above.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
