Implement Pessimistic/Optimistic Locking of records

[teian]

Like:
http://api.rubyonrails.org/classes/ActiveRecord/Locking/Pessimistic.html
http://api.rubyonrails.org/classes/ActiveRecord/Locking/Optimistic.html

Yii implementation of Optimistic Locking was posted on the forums.
http://www.yiiframework.com/forum/index.php/topic/5068-activerecord-and-optimistic-locking/page__p__71149#entry71149

This is pretty handy and would be awesome if implemented in the core!

[qiangxue]

Implemented optimistic locking in AR.
Pessimistic locking is too troublesome and is out of our scope, I think.

[rawtaz]

Very cool Qiang, that you just did it :)

May I ask what the API looks like for it, e.g. how do we control whether the locking should be applied/used?

[qiangxue]

AR has a method named "optimisticLock()". If you override this by returning the column name for storing lock version, then update() and delete() will support optimistic locking. In case a conflict occurs, a StaleObjectException will be thrown.

You have to manually generate the hidden field in the form because we don't want to couple the form widget with AR.

[teian]

awesome!

[rawtaz]

Nice. There's only one thing I'd like to adress: It would be preferable if one could use any unique field for the locking attribute - for example a timestamp named "modified" or similar (being part of a "created" and "modified" timestamp pair) would IMO be an ideal candidate for this, as that is something one might already have in most tables. By not having to create a new/specific field for the locking if there already is a unique field in the table, this would integrate more discretely/seamlessly (one can still create that separate field if wanted).

So basically I am asking, is it possible to use any unique column/attribute? If not, can you make it so?

Also, is there any use case where this needs to support a composite field/key for the locking? I can't really think of one right now.

[teian]

hmm after some consideration 2 things come up.

1. If you create a delete link, you have to put the lock id in a get param which would not be preffered. It would be good to have it like csrf with a param you set to true so that the lock param is also send by post.
2. i would also like to have it auto inject to forms when it's activated. I don't think this is to much overhead and would make it way simpler since you won't forget to include it yourself.

[qiangxue]

@rawtaz Yes, using existing column for lock version is supported, although timestamp is not precise enough to prevent the conflict (e.g. two people modify the same record within a second.) I don't think we need to consider about composite key.

@Tak0r We don't want to automatically generate such hidden fields because it would make the form widget coupled with this very specific AR feature. Even if the hidden field is generated, you still need to handle the logic of assigning the input data to this lock version attribute, which is ugly to do automatically.

[rawtaz]

Holy cow. Well, there's yet some fuel to my fire regarding MySQL.. I'm used to PostgreSQL which does it just fine, so I'll happily use my "modified" columns as the locking field :) Anyway, glad to hear one can use any unique column so it doesn't have to be an integer one :D