Undocument breaking changes in FieldTracker in Version 4.1

Problem

The Release 4.1, after moving the patch from the save() to the save_base() method in #404 (@tumb1er FYI) introduced a serioulsy breaking change that was neither announced nor documented (and was obviously not tested brefore). It would have deserved a 5.x update IMHO.

Since the values of the tracker are restored after the call to the save_base() method, any check/assumption made on the tracker inside the save() Method but after the super().save() call fails, as the tracker is then “new/empty”. This is especially problematic when tracking changes depending on related objects, when working with nested serializers per example.

Environment

• Django Model Utils version: <4.1 VS 4.1+

Code examples

class MyModel(Model):
        name = models.CharField(max_length=64)
        tracker = FieldTracker()

        def save(self, *args, **kwargs):
            if self.tracker.changed('name'):
                 print("True")
            super().save(*args, **kwargs)
            if self.tracker.changed('name'):
                 print("True")

Just calling MyModel.create() would result in 2 prints in version <4.1 and in only one in version 4.1+ (the second check will fail as the tracker is resetted on the save_base() call inside the `super().save() call)

Discussion / proposal

@auvipy A work-around is to test before the call to save() and then use the variable afterwards for such cases.

But I honestly find it quite a dramatic regression for the IMHO limited benefit of being able to modify update_fields in the save() Method.

I would seriously prefer to restore the previous behaviour of patching the save() Method, but still add a functionality to support overriding update_fields: I would prefer to add a new kwarg _always_update to FieldTracker where you could define the list of fields that you always want to update. I think also in term of design and readbility it would be a better feature. @tumb1er what do you think about the suggestion? If you validate it, I could draft a PR for this

[tumb1er]

I’ll try to find some time at weekend.

[MRigal]

@tumb1er we discussed offline with @gregorgaertner and we do agree that this is a great idea!

If you’re willing to, you could start with a PR and we could both review it. Else I was thinking to try to work on it, but I’m not sure when I’ll get the time for it.