Upgrade to django-pghistory 3.4.0

[quevon24]

• Update django-pghistory version in pyproject.toml and poetry.lock
• Update all @pghistory.track decorators in models to use the features of new library version
• Removed custom django-pghistory tracker, it is deprecated.
• Migrations for production (migrations only contain triggers)
• Update tests

[mlissner]

Did you see the setting that's now possible to set a default tracker?

[quevon24]

Did you see the setting that's now possible to set a default tracker?

Yes, i was thinking that maybe we could use the PGHISTORY_DEFAULT_TRACKERS for the models like Docket, OpinionCluster, etc and leave the custom decorators for m2m relationships like DocketTags, DocketPanel, etc.

Also should that setting go in the third_party directory or since it is so small should it go in django.py file?

It should look like this:

PGHISTORY_DEFAULT_TRACKERS = (
    pghistory.UpdateEvent(
        condition=pghistory.AnyChange(exclude_auto=True), row=pghistory.Old
    ),
    pghistory.DeleteEvent(),
)

[albertisfu]

@mlissner I reviewed this in detail, and it works properly after the update.

Just a couple of comments:

• We don't need SQL migrations for the trigger changes since we don't have triggers on replicas, right?
• Previously, m2m through tables generated events on updates and deletions. With this update, m2m tables now generate events only on the first insert and on delete. This makes sense because m2m instances can only be added or deleted (there are no updates).
• One change to note when implementing an admin for event tables is that we'll now have two types of pgh_labels:
  • The old one: update_or_delete_snapshot, which doesn't distinguish between updates and deletions.
  • The new ones: insert (for m2m tables), update, or delete.

[mlissner]

Sounds good, yes, no triggers on replicas. Does that mean we need tweaks here?

From the db guide:

[albertisfu]

Does that mean we need tweaks here?

No, this is good to go! We don't need SQL files since we don't need to apply those trigger changes to either our replica or customer replicas. There are some AlterField migrations, but they are no-op changes for SQL, as they only rename the related_name to "events" for Django.

[mlissner]

Wonderful. I'll merge and, @quevon24, if you can create a deployment issue for Ramiro, that'd be great.

[mlissner]

Merged. Thanks everybody!