Database locking

Ruby Apps Radiant CMS
1

I’ve setup Radiant for a client project and although it is a small
team that is editing it, I have run into a situation where two people
had the same page open and had overwritten each other’s changes.
John, have you (or anyone for that matter) considered adding a
feature that locks the page from editing when someone has it opened?
I’m curious are the arguments for or against this, or if it has even
been considered.

-Jim

2

On the table, but with an indefinite timeframe, is page versioning. Of
course, the core team would always welcome a contribution of code on
this
issue, via patch, etc. Generally John accepts patches that are cleanly
implemented and don’t add unnecessary complexity.

Sean

3

Great. It will likely become a priority for me in the near future, so
I’ll keep it clean and submit it for inclusion when its done.

4

Jim G. wrote:

I’ve setup Radiant for a client project and although it is a small
team that is editing it, I have run into a situation where two people
had the same page open and had overwritten each other’s changes.
John, have you (or anyone for that matter) considered adding a
feature that locks the page from editing when someone has it opened?
I’m curious are the arguments for or against this, or if it has even
been considered.

This is a problem. Locking systems are hard to implement for Web
browsers. Particularly, when one user “opens” a model object for an
indefinite period of time (they leave their Web browser open on the edit
page). Most systems work around this by warning you when you attempt to
edit a page “opened” by someone else, but not preventing you from
editing it if you insist. This can get pretty annoying as models are
invariably left open and repeated warnings aren’t fun.

Perhaps instead of locking, we should add a simple version constraint.
We could add a field to the page called version. Version would be
incredimented every time the page is saved. Before the save the page
would simply verify that the new version is only one higher than the old
version. If the versions were not correct we would know that someone had
edited the page in our absence and could request action from the user.

Would something like that be sufficient? Isn’t there a Rails plugin that
implements something similar?

–
John L.
http://wiseheartdesign.com

5

On Feb 1, 2007, at 11:28, John W. Long wrote:

that
implements something similar?

Yes. Exactly. That would do it. I’ll look into finding the plugin and
see how it’ll fit.

6

Perhaps instead of locking, we should add a simple version
constraint.
We could add a field to the page called version. Version would be
incredimented every time the page is saved. Before the save the page
would simply verify that the new version is only one higher
than the old
version. If the versions were not correct we would know that
someone had
edited the page in our absence and could request action from the user.

We’ve already got a version number - the modification date. All you’d
need to do would be to add:

And in the controller:

unless @page.updated_at.nil? || @page.updated_at.to_i ==
params[:last_modified]
flash[:notice] = “Some informative message here”
else
handle_new_or_edit_post
end

I just can’t think of the message to display to the user, but that’s
probably just a lack of sleep.

Dan.

7

Good stuff. Probably should belong in the model however, as a
validation.

Sean

8

John W. Long said the following on 02/01/2007 11:28 AM:

implements something similar?
On p222/3 of AWDwR-1 (Someday I’ll get to -2) there’s a note about
locking.
It seems RoR can do this. no need for a plugin.

Optimistic locking is enabled by default on any table that contains a trigger column lock_version. You should arrange for this to be initialized to zero for new rows, but otherwise lave it alone - ActiveRecord manages the details for you.

Apparently this doesn’t prevent a second opening, but if when you try
writing back the version# is compared and if it has already been updated
an
exception gets thrown.

Of course you have to catch the exception :slight_smile:
TNSTAAFL

–
Operationally, God is beginning to resemble not a ruler but the last
fading
smile of a cosmic Cheshire cat.
Sir Julian Huxley

9

I think it might actually be specific to the view/controller rather than
the model. When modifying the page from elsewhere, you should either
just do the modification without regard to locking or database locking
could be used. But either/or.

From: [email protected]
[mailto:[email protected]] On Behalf Of Sean C.
Sent: Friday, 2 February 2007 10:37 AM
To: [email protected]
Subject: Re: [Radiant] database locking

Good stuff. Probably should belong in the model however, as a
validation.

Sean