Choosing the Right Audit Trail Approach in Ruby

[irjustin]

This is Bemi's blog and their solution seems quite good for the larger scaled problems.

I'm rather experienced on Rails+PaperTrail and believe it to be a great solution for startups.

If you're looking at this for consideration, a few things I recommend:

- Critical models should get their own PaperTrail table.

- Install `--with-changes` always! The extra data is worth it. Direct DB changes, changes via `.update_columns` will all skip PaperTrail (Actually this is where Bemi could be helpful due to WAL based).

- PaperTrail is not true Disaster recovery, I argue Bemi isn't either nor are read-replicas. You want an off-site dump to be that.

[danielheath]

IME Papertrail really struggles when you have a top level object which owns a nested tree of associations; for that I would suggest implementing a canonical serialisation for each top level domain model and versioning that.

[ryanong]

Oh neat I haven't heard of console1984 or the package that allows for auditing. A lot of my previous companies have been looking for something like this

[riffraff]

The trigger based approach of logidze looks like it could just as well write data to a separate foos_audit_log table for each foos table, thus solving the table bloating issue, or is there a reason this isn't possible?

[Manfred]

It's certainly possible, but Logidze can't do that.

[Manfred]

One solution not mentioned in the article is writing entries to something like Logstash or other similar services specifically built for handling event logs.

[elsurudo]

Another option not mentioned here is event sourcing (or just using events in general to track changes)