← Alle berichten

An audit trail that is one word on the model

security/audit records model mutations: who changed what, when, and from what to what. Turning it on for a model is a single static.

Audit logging is the sort of requirement that arrives late, usually from outside: an accountant, a customer's security review, an incident where the question is simply who did this. By then the mutations are spread across routes, methods and background jobs, and retrofitting a log means finding all of them.

Which is why this sits under the model rather than beside it. Every write already passes through one place, so the log hooks there and nothing at the call site changes. Opt in per model, because logging everything is how an audit table becomes too large to read and too expensive to keep.

The interesting detail is what it records: the field-level before and after, not just the fact of a change. A log that says "user 12 updated invoice 908" answers almost nothing an hour later. One that says which fields moved and what they held answers the actual question.

One portability lesson came out of this. The table has a user column, which is a reserved word in PostgreSQL, and the writes were not quoting identifiers. It worked perfectly on MySQL right up until it did not work at all, and identifier quoting became the driver's job rather than a habit.

Engine 1.0. See audit in the manual.

We gebruiken essentiële cookies om deze site te laten werken. Met uw toestemming gebruiken we ook analytics om de site te verbeteren.