On Fri, February 9, 2007 2:18 pm, James Long said:
> On Fri, Feb 09, 2007 at 11:21:59AM -0500, Tom Lane wrote:
>>
>> Usually the best approach is to fetch the data without acquiring any
>> lock, allow the interactive editing to happen outside a transaction,
>> then when the user hits SAVE, perform a transaction that locks the
>> row(s), checks for conflicting changes, and commits if no conflict.
>
> Might you please expand on how the application could check for
> conflicting changes? Would this be simply fetching the record
> again, and comparing to the previously-fetched version, to see
> if the record is still as it was when the user started editing?
> Something more sophisticated?
>
> Thank you for your time.
That would be the simple way. More complicated ways might be needed in
more complicated scenarios. (Where, for instance, data has keep
relational integrity between two different tables, where you would have to
check that the records still existed in both before updating one.)
Exactly how sophisticated depends on the application, and the data. (And
the database design...) In some situations you might be able to come up
with a 'merged' change, where both changes are applied, but again that
depends on exactly what is being done.
Daniel T. Staal
---------------------------------------------------------------
This email copyright the author. Unless otherwise noted, you
are expressly allowed to retransmit, quote, or otherwise use
the contents for non-commercial purposes. This copyright will
expire 5 years after the author's death, or in 30 years,
whichever is longer, unless such a period is in excess of
local copyright law.
---------------------------------------------------------------
