Optimistic Locking and counters

Hi

I have a model which both have optimistic locking and a counter. Is there any way to disable the version auto increment when only the counter is updated?

Lets say I have a post which has many comments. When I add a comment I don't want the version_lock to be incremented. This happens now because the post has a comments_count column.

/mattias

Why do you care about version_lock value? That field is really for the AR “internal recordkeeping” part of optimistic locking. In .NET, this type of control is handled with a GUID, just to point out that the field value itself is useless outside of the scope of the locking mechanism.

Your thoughts?

Peter Fitzgibbons (847) 687-7646 Email: peter.fitzgibbons@gmail.com IM GTalk: peter.fitzgibbons IM Yahoo: pjfitzgibbons IM MSN: pjfitzgibbons@hotmail.com IM AOL: peter.fitzgibbons@gmail.com

This is because I in my edit view of the post also have a control panel for managing the comments (ajax). If a comment here is removed (without reloading the page and then also the post) the posts counter cache is updated alongside with its lock_version. If I then try to save the post its stale (StaleObjectError).

So I'm looking for a way to be able to update the comments counter cache on the post model without changing the lock_version.

This is because I in my edit view of the post also have a control
panel for managing the comments (ajax). If a comment here is removed
(without reloading the page and then also the post) the posts counter cache is updated alongside with its lock_version. If I then try to save the
post its stale (StaleObjectError).

So I'm looking for a way to be able to update the comments counter
cache on the post model without changing the lock_version.

I think you're better off fixing this properly than hacking around
with lock_version. If you post the salient parts of the code someone
might be able to offer a suggestion.

Fred

Something like this

p = Post.find(1)

c = p.comments.first c.destory

p.save

StaleObjectError

This fails because the counter cache of comments in the post model is now changed.

Anyway around this?

OK. So first off suppressing the increment of lock_version would probably meant that your counter cache value would get stomped on (although with partial updates in 2.1 you might get away with it). the easiest way would be to reload p after having done stuff to comments, or alternatively you might be able to do the stuff you need to do to p before you play with the comments. Yet another way might be to do stuff to c.post instead of doing them to p.

Fred

This was just to show the problem. The UI prevents me from reloading p.

This was just to show the problem. The UI prevents me from reloading
p.

That doesn't quite make sense to me. How can the ui stop you from
doing p.reload ? (or any of the other suggestions i made?)

Fred

Lets say:

1. User opens the post edit ui (which contains the control panel for the comments) 2. User edits the post but doesn't save 3. User destrys one comment through an ajax request 4. User tries to save the edit post

If I where to reload the post the users changes would go lost.

Does the variables the user posts include the lock_version (I would almost never do that) ?

Fred

Yes it does.

Yes it does.

Well if you don't do that you won't have this particular problem. Is
that there in order to handle concurrent edits by multiple people ?

Fred