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
on 2008-11-12 11:42
on 2008-11-12 13:58
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: firstname.lastname@example.org IM GTalk: peter.fitzgibbons IM Yahoo: pjfitzgibbons IM MSN: email@example.com IM AOL: firstname.lastname@example.org On Wed, Nov 12, 2008 at 3:42 AM, Mattias B. <
on 2008-11-12 14:06
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.
on 2008-11-12 14:17
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
on 2008-11-12 14:30
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?
on 2008-11-12 15:17
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
on 2008-11-12 15:21
This was just to show the problem. The UI prevents me from reloading p.
on 2008-11-12 16:06
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
on 2008-11-12 16:42
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.
on 2008-11-12 16:45
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
on 2008-11-12 16:55
Yes it does.
on 2008-11-12 17:20
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
on 2008-11-12 19:20
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