3 ms·
Choosing the Right Audit Trail Approach in Ruby
- deleted 2y ago[deleted]
- ryanong 2y agoOh 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 2y agoThe 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 2y agoIt's certainly possible, but Logidze can't do that.
- irjustin 2y agoThis 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 2y agoIME 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.
- Manfred 2y agoOne solution not mentioned in the article is writing entries to something like Logstash or other similar services specifically built for handling event logs.
- elsurudo 2y agoAnother option not mentioned here is event sourcing (or just using events in general to track changes)