Carbonite - Change tracking using triggers in PostgreSQL

Hello!

Came here to announce Carbonite, a data auditing library for Ecto/PostgreSQL.

In essence, Carbonite wraps an elaborate audit trigger function in some Elixir code to make it readily available in Elixir applications. A little bit of extra API allows convenient access to the audit logs. Its distinctive property, however, is its use of the database transaction as a natural “bracket” around tracked data changes. This bracket is enforced by an association between the change records and a central transactions table, where the foreign key is Postgres’ internal transaction id. The transactions table carries additional operation metadata (like the current user id).

It’s easier to see for yourself: Github, Docs

Carbonite is still very much work-in-progress. We’re currently collecting our first experiences with it, and are still changing the API around as we go. Still, any early feedback and thoughts are appreciated!

Let me know what you think!

Best,
malte

14 Likes

nice! any plans to support other DB adapters, or is it strictly postgres?

No plans, but would be open to contributions. Though it’s relying heavily on Postgres’ internal 64-bit transaction id, not sure whether there are equivalent things in other RDBMS. So for now, it’s Postgres-only.

Fantastic! I’ve debating building something just like that for years.

I always hated the rails style approaches where it only tracked changes if made by a specific object in a specific library that made sure not to use any group update functions.

I hear you. Just had to work around this last week.
Had to work on a pretty big collection so ActiveRecord’s update_all was perfect for the job. But then I had to manually implement the audit because our current solution relies on the AR callbacks.

2 Likes