enova/audit_star

Database change auditing.

audit_star's Issues

Needs lock safety

Not sure if this should be the responsibility of audit_star itself or your migration framework, but the audit_all method doesn't have anything to prevent long lock contention resulting from waiting for a lock which lock_timeout would prevent.

Snapshot views are not accurate

The *snapshot views created by audit_star are not accurate. In order to show a change history accurately, a recursive query is going to be required. Here is an example of what shows instead of what should be shown in the snapshot view.

Given a record with the following 3 changes, the "customer_id" only gets set to a value on the 3rd change

audit=# SELECT foos_audit_id, changed_at, change FROM service_audit_raw.foos_audit WHERE primary_key = '7068' ORDER BY foos_audit_id;
-[ RECORD 1 ]----------+----------------------------------------------------------------------
foos_audit_id | 2176
changed_at             | 2016-08-14 00:21:13.740758
change                 |
-[ RECORD 2 ]----------+----------------------------------------------------------------------
foos_audit_id | 2177
changed_at             | 2016-08-14 00:21:13.740758
change                 | {"pending": "f", "updated_at": "2016-08-14 00:21:13.807175"}
-[ RECORD 3 ]----------+----------------------------------------------------------------------
foos_audit_id | 2178
changed_at             | 2016-08-14 00:21:13.740758
change                 | {"customer_id": "3215620", "updated_at": "2016-08-14 00:21:13.830382"}

However, here is what the snapshot view actually shows:

audit=# SELECT foos_audit_id, customer_id FROM service_audit.foos_audit_snapshot WHERE primary_key = '7068' ORDER BY foos_audit_id;
-[ RECORD 1 ]----------+--------
foos_audit_id | 2176
customer_id             | 3215620
-[ RECORD 2 ]----------+--------
foos_audit_id | 2177
customer_id             | 3215620
-[ RECORD 3 ]----------+--------
foos_audit_id | 2178
customer_id             | 3215620

It should show NULL for customer_id until the very last record.

Misleading behavior for excluded_schemas

We expected that the list of excluded_schemas would be based on direct match, but we were surprised when we configured to exclude one schema which is the prefix of another, and both schemas were excluded!

We found this: https://github.com/enova/audit_star/blob/master/audit/audit.go#L276-L284

This should either be based on a direct match, or the docs should be updated to clearly reflect this.