Yeah, I hear you. It's basically the iterator pattern though, e.g., just as in a jdbc result set - you call next() before you can read any data. Also, in a transactional MVCC context, a call to CURRVAL that is not preceded by a call NEXTVAL would be be ill-defined. When you call NEXTVAL you get a unique value from the sequence that is defined for your transaction. Calling CURRVAL afterwards will give you the value of NEXTVAL last returned for your transaction. However, if your transaction/session calls CURRVAL before NEXTVAL the database would have to return the value from some other transaction, and if multiple transactions are in progress this would not be uniquely determined. Thus the error. On Mon, Mar 2, 2009 at 8:06 AM, Evan Nelson <[email protected]> wrote:
> > Interesting. That just seems like a blatantly stupid way to implement > a sequence... but, if that's the way Oracle does it, then I guess > that's the way we need to support it. > > Thanks for the info, I appreciate it. > > -Evan > > On Mar 2, 1:28 am, Johann Schleier-Smith <[email protected]> wrote: > > The START WITH value for a sequence is returned after the first call to > > NEXTVAL, so the H2 implementation and tests are sensible. > > For comparison I ran this code in Oracle. It throws an error (ORA-08002) > if > > call TESTSEQ.CURRVAL before TESTSEQ.NEXTVAL. Returning start with minus > > increment rather than an error for an initial call to CURRVAL is a > > reasonable implementation. > > > > On Sun, Mar 1, 2009 at 5:16 PM, Evan Nelson <[email protected]> wrote: > > > > > I've been banging my head trying to figure out why my new code for > > > SEQUENCEs isn't passing the tests stored in the testing script. I > > > think it's because the tests are all based on an incorrect > > > implementation of SEQUENCE! > > > > > In the current version of the code, try the following: > > > > > CREATE SEQUENCE testSeq START WITH 5; > > > SELECT testSeq.currval; > > > > > Because this sequence is starting with 5 and we haven't modified it, > > > it stands to reason that currval would return 5, doesn't it? It > > > doesn't do that, though. Instead, it returns 4. Similarly, the > > > following SQL code... > > > > > CREATE SEQUENCE testSeq START WITH 10 INCREMENT BY 3; > > > SELECT testSeq.currval; > > > > > ...will return 7. In Sequence.java, the value is stored correctly, but > > > the function "getCurrentValue()" returns the current value minus the > > > increment. However, all the script tests seem to think this is normal. > > > Am I missing something, or isn't this incorrect behavior? > > > > > -Evan > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "H2 Database" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/h2-database?hl=en -~----------~----~----~----~------~----~------~--~---
