There’s a standard way of handling object updates via HTML forms. Generally speaking, when the user selects an object to edit, you populate an HTML form with all the data from the object, post all these fields when the user presses Submit, then update all the fields of the record with the data in the HTTP request.
So, if I’m going to edit an article, the HTML form contains all the article properties, and — even if I just change one — the SQL that results after I press Submit rewrites ALL the fields with what it receives in the request.
This has always made me just a little nervous because is assumes that the request is perfectly accurate — that it accurately represents what we want the object to become. But is this always the case?
I did this very thing, I just had hidden field with MD5's for each string, when it got back to the server, I rechecked the MD5's and updated only the strings that changed (via dynamtic SQL). MD5's are not perfect (1 in 100,000,000), but good enough for my needs. If you had to be 100% sure, just dup the string in a hidden field. Compare when it gets back to the server.
I tend to read the columns of the record to be changed into a hash (I use Perl), then use a simple "eq" comparison to identify the changes and prepare a dynamic "UPDATE" command before issuing that UPDATE to the DB. It's quick, efficient and very reliable.
Yes, that addresses the efficiency issue, but what about the problems caused by UI bugs? If you compare the existing object with what's in the request, you still don't find problems caused by a malfunctioning UI.
"What about the problems caused by UI bugs?"
With all due respect Deane, this shouldn't be an issue at all. The back-end application SHOULD have sufficient integrity checks, input validation, taint checking and error-handling to cope with any failing of the UI.
If this isn't the case, then you have bigger problems to consider: for example, the user (or script) that deliberately submits data that can compromise the database!
