Huh, was actually thinking of making something like this myself. A question though, I notice that it seems to require a User schema of some form to mark whodoneit, however in my system the User is in an LDAP system (not exposed via Ecto since Ecto2 has no LDAP interface, as well as it would not work cross-repo anyway), and the unique ID from the LDAP database is a bigint integer in Ecto. How would I give it the bigint unique ID that does not have a corresponding ecto schema?

It does not need a user model if you don’t want to track who made the change. Please add an issue if want to see support for an LDAP based user model.
To suport your use case, I think we can add an option to the installer for this. Something that would set the user_id to a simple field with a provided type. For the user name, we could add support for a {module, fun} tuple and call the fun if its a tuple.

What do you think?
Steve

Just as a comparison, my original idea for a module like this was less generic, I was planning an interface to use PostgreSQL’s natural ability to mark rows as ‘deleted/invalid’ and they no longer appear after in SQL queries (unless you use a specific one to get those specifically deleted ones), thus you can version that way. Could store something like a user on the table itself for example. I am unsure which method is better actually…

There are a few ways. PostgreSQL used to have actual Time Travel functionality built in a long time ago but was removed for ANSI compliance over time and is now emulatable via: https://www.postgresql.org/docs/9.5/static/contrib-spi.html#AEN174541

Honestly that is overkill though, and database specific (which much of my code is anyway), and I am using such a row history as it is on one of my tables. On one of my tables I need to keep all history, and yet it is dynamic. I could have made a logging table but that is extra work so all I did was add a column of (in addition to the other primary keys):

field :invalidated_at, :datetime, primary_key: true

On initial write I set it far in the future (specific date of 294275 AD), on every query I add the 294275 AD date to the query via a helper on the schema. On write I update the :invalidated_at of the old row to now() and write out the new row with the new data with the 294275 AD future date. On delete I just set the :invalidated_at to now(). This is not a generic style that would be useful in most situations, not a good style for storing, say, who did it, although with minor modifications to some of the ordering it would be.

That table grew over a few versions to do that, I was thinking of redesigning it (would not need to be a primary key with an idea I have) with a set of helpers that I could pull out into a library to manage it for me, something as simple as just dropping another timestamps-like call into the migration and schema with a set of options it could take along. It would have been postgresql specific due to using its built in time handling functions though.

I just published 0.2.0 on hex. This version has a mix whatwasit.install —whodoneit-map option that will save your user struct in the database as a map. This should work with any struct and not just an Ecto schema.

Steve