A few questions about ex_audit HOT 3 CLOSED

How does it deal with adding and removing fields in the schema?

It doesn't do anything special about it. Since it stores diffs of the data, it will have the changed field in the change list as an addition or removal the next time a change is recorded.

How to deal with data migrations (in migrations you cannot really use schema names as they might change or be removed)

I'm not sure what you want to achieve here. Do you want to change recorded versions or add a new version with the changes done in the migration? Let me say it like this, ex_audit won't prevent you from modifying the versions table manually, but design wise I haven't thought about this.

Would it be possible to also add a version that is not yet applied to the DB (like a draft).

Sure, you could add another field to the version schema that is a flag if something is a draft, and record the change manually, but I think this would be shoe-horning a feature ex_audit wasn't meant to do.

from ex_audit.

How does it deal with adding and removing fields in the schema?

It doesn't do anything special about it. Since it stores diffs of the data, it will have the changed field in the change list as an addition or removal the next time a change is recorded.

Neat this wasn't clear to me, but if it's just the diffed fields that's nice. I think this is indeed the best approach. When a field is deleted and it is present in a diff I presume nothing happens (no failures).

How to deal with data migrations (in migrations you cannot really use schema names as they might change or be removed)

I'm not sure what you want to achieve here. Do you want to change recorded versions or add a new version with the changes done in the migration? Let me say it like this, ex_audit won't prevent you from modifying the versions table manually, but design wise I haven't thought about this.

I was more thinking along the lines of when you add new fields with default values or values derived from other fields. As it just reverts diffs, it would handle that fine (probably the versions table doesn't need any change).

Would it be possible to also add a version that is not yet applied to the DB (like a draft).

Sure, you could add another field to the version schema that is a flag if something is a draft, and record the change manually, but I think this would be shoe-horning a feature ex_audit wasn't meant to do.

Yes went through the source code and with the diff approach future versions will be tricky. I think it's better to have a separate library that just stores a changeset/forward diff in a "drafts" table.

What would be super helpful for me is:

• A history function that is limited to the last # or versions (to solve a potential scaling issue when there a LOT of versions)
• A way to handle many-to-many relationships and storing them in the diff (do you already have an idea how to handle that?)

Both I can potentially PR.

from ex_audit.

What would be super helpful for me is:

A history function that is limited to the last # or versions (to solve a potential scaling issue when there a LOT of versions)

That's not possible currently, because it's only storing diffs. It could be solved by adding "keyframes" (like MPEG does it).

A way to handle many-to-many relationships and storing them in the diff (do you already have an idea how to handle that?)

This would need an extra table with 2 entity_id fields.

from ex_audit.