AR performs broad updates - that is, when you save an AR record, every field in that record is overwritten.
This can cause concurrency problems.
Let’s say the user pulls up his user profile form - and at about the same time, an administrator pulls up a form that displays the same attributes plus some that are only accessible to administrators.
If the user submits his changes before the administrator does, the user’s changes are overwritten and lost - and the other way around.
Note that I’m not talking about milliseconds here - certainly those updates where a record is loaded, changed, and saved back directly can result in potential problems, but you would probably work around those specifically in an area of an application where data integrity is extremely important.
I’m talking about the interim between the time you pull up the form until you submit it. We could be talking anywhere from 1 to 20 minutes here, it all depends. So there’s actually a fair chance that this will happen.
Unfortunately, there is no simple way to work around that. My first thought was that AR should only update those attributes that have actually been changed. But in the example above, if the administrator submits his form last, on the server-side, that model will reload and attributes will be applied, and they will appear to have changed, simply because they no longer match what the user just committed to the database.
The only way I can think of that would work, is to put a hidden field in the form, containing checksums for each of the current attribute values. That way, when the form is submitted, you can compare the submitted checksum against the checksum of the submitted value, to see if the user actually changed the values on the form. If they weren’t changed, don’t apply the attribute values.
Maybe this is something to be implemented with an extension rather than a framework feature?
On the other hand, this could be generally useful to anyone who runs into these concurrency problems…