-
-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add restore and revert actions dependent on diff change tracking #12
Comments
Change tracking would require a full diff: Proposed structure for an update change with snapshot: {
subject: { from: "subject", to: "new subject" },
body: { unchanged: "body" }
embedded_author: {
first_name: { unchanged: "Jane" },
last_name: { from: "Doh", to: "Doe" }
}
embedded_tags: {
"tag-3": {
op: "create",
changes: { tag: { to: "ash" } }
index: { to: 0 }
},
"tag-1": {
op: "update",
changes: { tag: { unchanged: "phoenix" } },
index: { from: 0, to: 1 }
},
"tag-2": {
op: "destroy",
changes: { tag: { unchanged: "nerves" } },
index: { from: 1}
}
}
} Same changes but changes only: {
subject: { from: "subject", to: "new subject" },
// body is unchanged
embedded_author: {
last_name: { from: "Doh", to: "Doe" }
}
embedded_tags: {
"tag-3": {
op: "create",
changes: { tag: { to: "ash" } }
index: { to: 0 }
},
"tag-1": {
op: "update",
// no changes, only moved index
index: { from: 0, to: 1 }
},
"tag-2": {
op: "destroy",
index: { from: 1}
}
}
} |
This will take some time to get right. One of the difficulties is that we're building a schema here that could ultimately need to change in the future which would be problematic. I'd also suggest potentially only storing the |
Yeah, that make sense. It will be more expensive, it would need to go back until it gets values for each field, or if its backed by ecto like AshPostgres maybe use a fancy query. |
I’d prefer just making it configurable with different change_tracking_mode.
If `from` is stored, it’s really easy to do an undo / revert.
I think we can make the actions smart enough to validate error on changes.
It would also be left to use to developer to make a UI that makes sense.
I’m actively working on these features but the more complex ones I’m
starting with mixins.
|
The issue about storing |
I understand now. That’s not really a concern for my use case. Things I’m
versioning rarely get writes. I think I’d be ok just warning against that.
I want these as audit logs. The fancy Postgres query won’t work for me.
|
👍 Something we could also do is add a change to lock records on all updates automatically, and explain that in the docs. In your case if they aren't written to frequently, that should be okay. |
Breaking this into three issues:
|
RFC: For snapshot change tracking, add restore and reverts actions which would require a full diff and snapshot.
Normal validations and policies would apply to the source version
The text was updated successfully, but these errors were encountered: