Choosing the Right Audit Trail Approach in Ruby

blog.bemi.io

46 points·exAspArk··7 comments

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.

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.

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

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?

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

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

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

Reply on news.ycombinator.com