Why not to use built-in features of RDBMs for OCC?

  1. For MSSQL timestamp/rowversion (http://technet.microsoft.com/en-us/libr ... 82776.aspx)
  2. For Oracle ORA_ROWSCN http://decipherinfosys.wordpress.com/20 ... ncurrency/
  3. For postgres xmin - http://www.postgresql.org/docs/8.2/stat ... lumns.html

This thread was imported from our support forum. The original discussion may contain more detailed answer.

asked Mar 25 '10 at 11:49

pil0t's gravatar image


One Answer:

Built-in version columns appeared many years ago to simplify automatic version change in manually written SQL, but now we have a bit different case. Imagine:

  • They invented a special data type for this! // Why? And why just one?

  • You actually don't have much control of the provided behavior

  • In many cases there is no necessity for an additional column (e.g. for m-n relationship tables). They can't help here at all.

  • The same idea is implemented differently in almost any database - that's bad.

  • Finally, it's necessary to read the new value of such version after update. In our case it's simply known.

So for me this is nearly the same case as stored procedures or triggers: they appeared to solve the problem, that doesn't exist, if there is an ORM + solid BLL framework. Or, more precisely, exists, but it's much easier and convenient to solve it @ higher level now.

Although we must anyway think about supporting such versions in Legacy mode.

answered Mar 25 '10 at 17:57

Alex%20Yakunin's gravatar image

Alex Yakunin

Your answer
Please start posting your answer anonymously - your answer will be saved within the current session and published after you log in or create a new account. Please try to give a substantial answer, for discussions, please use comments and please do remember to vote (after you log in)!
toggle preview


Once you sign in you will be able to subscribe for any updates here



Asked: Mar 25 '10 at 11:49

Seen: 10,663 times

Last updated: Mar 25 '10 at 11:49

powered by OSQA