django-pghistory

django-pghistory copied to clipboard

First, thanks a lot for this package, I really wanted to build something similar for quite sometime.

I have a requirement for knowing what was the operation (insert, update or delete) and also track deletes snapshot.

I ended up splitting Snapshot into 3 other classes SnapshotInsert, SnapshotUpdate and SnapshotDelete so we could also use just the ones you need, like: @pghistory.track(pghistory.SnapshotDelete()).

What you guys think about it? Let me know if this is an interesting contribution and if I can improve the code in anyway.

@nossila thanks so much for your suggestion and code.

I've been unavailable for some time to contribute and am finally coming back around to merging in some of these PRs.

At a high level, I'm very cautious of accepting a change that modifies the default tracking tables. Some customers have hundreds of millions of snapshot rows, and they'd have to migrate all of them.

Let me come back to you with some thoughts on how we can try to handle this use case though. There may be something I didn't fully document that may support your use case well.

One question that comes to mind though - Is it possible for you to determine this information dynamically? Correct me if I'm wrong, but the the first snapshot of a row is always going to be an INSERT, everything in between will be UPDATE, and the final one will be DELETE if the original record no longer exists. I believe the only time this case doesn't apply is for legacy data where you weren't tracking events.

Let me know though. I will come back with some more thoughts

Thought about it some more. I think this would fit better as a custom base model you set for every snapshot model in your project using this setting

The triggers would have to either treat a pgh_operation field specially, or the base model would have to do something special to adjust the current triggers. I think it could work either way.

In other words, the change wouldn't affect any current users, and it should solve your use case. We can put a section in the docs on this other base model for users that need this additional metadata.

Let me know if that makes sense and perhaps I can propose or make some changes to the PR.

Final update - I looked into the pghistory code a bit more, and it would be trivial for me to add a special case around the pgh_operation field. I.e. I can add this in the triggers, and then users could simply add a pgh_operation field to the base model in their projects if they want it tracked.

Let me know if that makes sense and if it would work for your use case. I can get it in fairly quickly