I admit that I skimmed through the start of the thread, and had assumed
by "hash" you meant a hash object containing the original {
columns=>values }; I also assumed that DBIx::Class kept that hash of
original values in memory, however I've just checked
DBIx::Class::PK::discard_changes, and seen that it doesn't.However ... Dan Horne wrote: >Well if I can't add an extra column (either hash or version), wouldn't I >need to read the whole row and recompute the original hash with every update >or delete to every single row? Sounds expensive to me, which is why I moved >away from using hashes as I originally proposed. > > An option would be to keep original column values in memory (copy on change), and then on ->update(), add col1=orig_val1 AND col2 = orig_val2 AND ... to the SQL update where clause. Can your module do that? >The alternative version column approach is a common optimistic locking >design pattern and is supported by Hibernate and Toplink, for instance. I >guess it comes down to whichever ORM you wish to cite... > > > True -- I don't have wide experience with such things, but find the ADO.Net approach nicely straightforward, and you don't even need to know that it's doing it. _______________________________________________ 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]/
