Re: Question on best practice for allowing edits of lists

On Thu, 28 Jul 2005 11:38:26 -0700, bingomanatee wrote:

> One concern with the process of editing records is simultaneous editing.
>
> That is user A clicks on the link and begins editing..
>
> Then user B, a quicker sort of person, does the same thing and SAVES
> FIRST.
>
> User A is still on the form page, plodding along and finally finishes and
> hits the SAVE button, overwriting B's changes.
>
> The classic rule is that you shouldn't be able to save over a record that
> has been edited underfoot.
>
> The easiest way to check this is to use a timestamp field (I'm using mySQL
> vernacular) -- that is, a field whose date is set every time the record is
> saved. (You can use a conventional date field and manually set it to now()
> using SQL every time you save. I tend to call this field "updated" by
> convention.
>
> Load the old 'updated' field into a hidden field on the form.
>
> The form will submit to a save_record.php page (or some such) and on this
> page, BEFORE YOU SAVE, do a SELECT to determne the records' current value
> for 'updated'. if it is different from the 'updated' value that the record
> had when you loaded it, don't resave the data. give the user an error
> message ("Your record has been edited by someone else; your changes
> haven't been made. ) and return them to the list view. If they want, they
> can click on the record and edit it again.
>
> Also, in the event that someone else has deleted the record, you might
> want to check that there is a record in the system with the current ID.
>
>
> Ideally you'd have a "check out" system that prevented user B from opening
> the record when user A was editing it, but in the web environment it's
> very problematic to do this because its tough to determine when the user
> has shifted gears (left the edit page without saving the record) so "stale
> checkouts" are common.
>
> These security measures are most necessary in data held in common by
> several users. Private records like BLOG pages or user_ID records probably
> don't need asynchronous edit protection.

Why suggest a method that you admit doesn't work? You *don't* need a
timestamp at all ( although it's always handy ). What you need is the
values for all editable fields at the time the update window was opened.

So, stuff a copy of each of these fields into a hidden field or session
var, and then, at update time, check to see that all of those values are
still the same as those stored in the database for the entry in question.

If they've changed, then you can use logic to see whether any of the
current changes are logical, and see how clever you can be in resolving
the problem. Personally, I'd be braindead stupid and refuse, although you
could probably get away with silently ignoring the update if the changes
to be made have all been done by someone else.

The overhead of checking many fields rather than one will never be that
big. As the changes are being made manually, and people don't type that
fast - you'll only ever have a slack handful of changes to make to a
single record.

No stale anything - guaranteed success ( assuming that the select / update
method is atomic, which it isn't ).

My $0.02,

Steve
.

Quantcast