In my work creating a plugin whose purpose was to audit changes and
creations to table data.
My auditing plugin inserted itself after the main set_column stage,
checked the dirty flag, and recorded the change for audit (at final
insert time) when the column was dirty after the set.
This didn't work for inserts, though it worked for updates.
I discovered that on insert, the system uses the ->store_column method
rather than the ->set_column method - thus overriding set_column was
ineffective at capturing information regarding all changes in the row
object!
I had to manually check the column data before and after within a
store_column augmentation, to see if it changed, since the dirty flag
was NOT telling me if it was, indeed, a dirty column.
Messy.
My question: What is the reason that changing column data (in this case
the change from nothing to something in a new row object) is *not* to
use set_column, thus setting the dirty flag for the column?
Curious,
David
_______________________________________________
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/[email protected]
