Dan Horne wrote: >> On Behalf Of Zbigniew Lukasiak >> >> Hi, >> >> There will be race conditions - is that acceptable for you? See following > scenario: >> Person A wants to save new record values >> Person B wants to save new record values >> A fetches the record to compute the hash >> B fetches the record to compute the hash >> The record has not been changed yet so both A and B are ready to save > their new values >> A saves her new values >> B saves her new values >> >> The result is that the values saved by A are overwritten by B without any > warning. >> It would be safe if we could do a >> >> UPDATE rec ... WHERE (id = our_id AND hash = the_old_hash_val) >> >> This would be a real optimistic locking using the database mechanisms to > eliminate the race conditions. >> -- >> Zbyszek >> > Yes, I've been thinking about this in the meantime and have decided to add a > version column to each table and do something similar to what you suggested > > UPDATE rec set col1 = <col1>, col2 = <col2> ... version = version + 1 ... > WHERE conditions and version = old_version_value
If you're doing that, can you bear in mind that it'd rock if we could extend that later to add change auditing please? :) (I was going to implement that but the project I needed it for got cancelled so it's gone onto the back-burner for the mo) _______________________________________________ List: http://lists.rawmode.org/cgi-bin/mailman/listinfo/dbix-class Wiki: http://dbix-class.shadowcatsystems.co.uk/ IRC: irc.perl.org#dbix-class SVN: http://dev.catalyst.perl.org/repos/bast/trunk/DBIx-Class/ Searchable Archive: http://www.mail-archive.com/[email protected]/
