django-pghistory

django-pghistory copied to clipboard

We've noticed that sometimes the only fields that have changed are auto_now fields and they're creating lots of event records we don't really care about.

To deal with this, we made a custom tracker that has an extra parameter, ignore_auto_now. When set to true, it ignores changes to models that only affect auto_now fields.

In usage, it looks like this:

@pghistory.track(CustomSnapshot(ignore_auto_now_fields=True))
class Note(models.Model):
    ...

We'd be pleased to do a small PR with this new feature, if the maintainers were interested. Any interest?

I currently use pgtrigger to revert any auto_now field updates, and to update the auto_now fields only when other fields are actually updated. Your feature would be a welcome addition to pghistory. Maybe even expand it to ignore a list of specified fields?

Great!

Maybe even expand it to ignore a list of specified fields?

So perhaps like this:

@pghistory.track(CustomSnapshot(ignore_fields=["date_modified", ...]))

And the docs could explain that ignored fields show up in the event models but do not trigger new events if they're the only changed field?

One other thing, @mrvisiol, are you a maintainer of this project?

Great!

Maybe even expand it to ignore a list of specified fields?

So perhaps like this:

@pghistory.track(CustomSnapshot(ignore_fields=["date_modified", ...]))

And the docs could explain that ignored fields show up in the event models but do not trigger new events if they're the only changed field?

That's exactly what I was thinking.

(And no, I'm not a maintainer of this project.)

@mlissner @mrvisiol

To clarify, you want these fields to show up in the snapshots, right? If it wasn't already known, you can ignore the fields entirely with exclude (see the section here towards the end about this particular argument). I need to double check, but excluding these fields would also no longer trigger snapshots. Since snapshot models already include pgh_created_at, you may not really need auto updated fields in your snapshot models in the first place. Would this solve your issue?

If not, you'll need to use the condition argument for this (see conditional tracking for an example ) . Your condition will need to OR together any changes of the fields you care about. Check out the pghistory code itself to see how it makes this condition for when exclude is used.

It's not pretty code.. This is one of the more awkward conditions to make, and it's pretty common too. However, conditions have to be written this way since history is tracked using triggers

How about this - Let me make a custom Condition object that you can use to more easily express conditions where you want to ignore fields. If this solves your problem, I can post some code here with the intent of getting it into django-pgtrigger so that everyone writing trigger conditions can use it.

Hope I understood your problem correctly. Let me know if I didn't

I think @quevon24 has some pretty simple code for this that he put over in #85 before I asked him to move it to a separate PR. The general idea though is that we want to store the values of a field in the history table, but changes to the field shouldn't trigger new history events. Some fields change too frequently to trigger history events each time they change, but I'd like to know their last value when something else in the model changes.

Kevin, could you please post in your snippet for doing this that you had?

This isn't the most important feature for us, if we need to, we'll either build it into the other PR or we'll just exclude the field entirely, but it'd definitely be nice to be able to do this.

As discussed in https://github.com/Opus10/django-pghistory/pull/85, users are able to create manual trackers a bit more easily now using the pghistory.Changed condition. I have an example tracker in the test suite here and an example test that validates it

It's not the prettiest solution, but I think long term it might be better to break the API and consolidate the Snapshot tracker and all of the other utility trackers since they have subtle differences in what they do.

I will keep this issue open for now until I add an example to the docs. The PR was deployed in v2.7!