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