Optimistic Locking and counters

Rails
1

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

2

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 F.
(847) 687-7646
Email: [email protected]
IM GTalk: peter.fitzgibbons
IM Yahoo: pjfitzgibbons
IM MSN: [email protected]
IM AOL: [email protected]

On Wed, Nov 12, 2008 at 3:42 AM, Mattias B. <

3

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.

4

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?

5

On 12 Nov 2008, at 12:06, Mattias B. wrote:

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

6

On 12 Nov 2008, at 12:30, Mattias B. wrote:

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

7

On 12 Nov 2008, at 13:21, Mattias B. wrote:

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

8

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

9

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.

10

On 12 Nov 2008, at 14:42, Mattias B. wrote:

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

11

Yes it does.

12

On 12 Nov 2008, at 14:55, Mattias B. wrote:

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

13

Frederick C. wrote:

On 12 Nov 2008, at 14:55, Mattias B. wrote:

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

Exactly