On Thu, Nov 2, 2017 at 1:44 PM, Jeremy Evans <[email protected]> wrote: > On Thursday, November 2, 2017 at 2:33:12 PM UTC+1, Satyanarayana Gandham > wrote: >> >> Hi, >> >> In sequel gem, how can accomplish the following: >> * Store/Log every time a model is changed. Store/Log which properties are >> changed, old value, new value and changed by whom? >> >> Is there a plugin which does it? > > > In general auditing should be done by a database trigger. You can do it > with a before_update/before_delete hook in Sequel, but it is not as nice. > > Instead of storing changes, just store a versioned copy of the row in a > separate table. You can do comparison between rows of the auditing table to > get old/new values. For "changed by whom", have the main table store a > "last_modified_by", and then you know who was responsible for each > modification.
note that _versioning_ and _auditing_ are pretty different things. i think Jeremys approach is better suited to _versioning_. if you want to look at some log and figure out wat users did that caused teh db to reach a certain state, then you want to _audit_. in this case, teh program should write detailed info about teh _request_, such as who is to blame and which data was affected (it could span multiple tables), to a log. this log could be cerealized on plain text or on teh db, possibly in jason. however, you may want your program to do _versioning_. in this case, i would make two tables: _main_ and _version_. _main_ would be a map from teh primary key to teh latest _version_, containing teh actual data. upon insertion of a new _version_, teh matching _main_ row would be updated by a db trigger (or model callback if you are lazy liek me). i prefer a main/version over Jeremys approach because it avoids duplication. this way your code just need to handle one sauce of data, not two, and migrations are simplified too. you really want your _versioned_ stuff to be updated with teh software, so that newer versions of teh program will be able to read older versions of models. and you really want your _audit_ log to be verbose and immutable as possible, so you get a nice picture of wat was going on back then. in either case, i find it hard to make a good general solution. there are auditing gems to Rails, such as papertrail, but they are far from smooth. -- Igor -- You received this message because you are subscribed to the Google Groups "sequel-talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/sequel-talk. For more options, visit https://groups.google.com/d/optout.
