What data type is the @version meta data?

I can’t seem to find any reference of what data type (i.e. an integer to be sure, but how many bits) the @version number is in the record meta data. I’m trying to determine if I should ever worry about it rolling over.

Hi @eric24

The record version is a signed integer

Thanks

Luigi

@luigidellaquila - So 32 bits? OK. That brings up two additional questions:

  1. What happens when it rolls over (does it restart at 0 or at negative MAXINT)?
  2. Other than rollover (if it does go negative), what would be the case of a negative @version number?

Hi @eric24

Not sure if it restarts from zero or from Integer.MIN_VALUE, I should check, but it does not make much difference in general.
If a record is saved with the wrong version, you have OConcurrentModificationException, regardless of the fact that the version is higher or lower.
The only problem would arise if you save the exact same record with the exact same version but after exactly one round-trip, so that the versions match perfectly, but it’s quite unlikely with a range of two billion versions

Thanks

Luigi

@luigidellaquila - That makes sense. The only thing I can really “know” about the version is that it’s different than what I read earlier–it’s actual value and how it rolls over is opaque, and there is no special meaning of negative values (if they even exist), like there is with RIDs.

By the way, when using SQL to do an UPDATE, other than to check for @version differences myself in my code, is there a way to make use of the OConcurrentModificationException or similar? Or is this part of the driver? I’m using OrientJS in node.js.

Hi @eric24

The easiest way to deal with OConcurrentModificationException in SQL is to use batch SQL scripts with

BEGIN;
...
COMMIT RETRY x;

Thanks

Luigi

@luigidellaquila - Sure, but there are times when I want the update to fail so I can inform the user that a change has been made since they read the record. How would you handle that? Specifically, I read a record with @version = 10, then a few minutes later, the user saves an update to this record, but in the meantime another user has made a change, so the stored @version is now 11. If I just do the first user’s update, it will work just fine and be “invisible” (unless I explicitly include the @version in the WHERE). Is that the right way (to include the @version in the WHERE) or is there some built-in way to handle this?