Make context middleware extensible by @wesleykendall in #141.

Inherit pghistory.context.HistoryMiddleware and override get_context to add additional context data for every request.

Support offline documentation formats by @wesleykendall in #144.

PDF versions of documentation are built via ReadTheDocs.

Ensure BigAutoFields are properly mirrored in history models by @tobiasmcnulty in #134.

!!! warning

  If you have event models for models with `BigAutoField` primary keys, you will see new migrations to convert `pgh_obj_id` to a bigint.

Support filtering event models by referenced proxy models by @lokhman in #135.

Ensure bytes representations of SQL are handled by @tobiasmcnulty in #136.

Fix setting default trackers with the PGHISTORY_DEFAULT_TRACKERS setting by @SupImDos in #133.

Don't install pghistory's context tracking function on non-postgres databases by @pmdevita in #132.

Ensure MiddlewareEvents doesn't filter out non-middleware events in the admin by @lokhman in #130.

Support custom primary keys for the aggregate Events proxy model by @lokhman in #128.

Fix type hints for pghistory.track by @SebastianDix in #118[#118].

Support named arguments in SQL by (@foobarna)[https://github.com/foobarna] in (#111)[#111].

Fix Empty List being passed into create_event_model [Maxwell Muoto, b89c86d]

Fix Empty List being passed into create_event_model

Django 5.0 compatibility [Wesley Kendall, 934ca6d]

Support and test against Django 5 with psycopg2 and psycopg3.

V3 release with new event trackers [Wesley Kendall, 8849fc6]

Version three of django-pghistory has some of the following breaking changes:

• Removal of code deprecated in version 2.5 related to configuring event models
• Consolidation of the event trackers. pghistory.Snapshot and all custom event trackers such as pghistory.BeforeDelete and pghistory.AfterInsertOrUpdate were consolidated into three core event trackers: pghistory.InsertEvent, pghistory.UpdateEvent, and pghistory.DeleteEvent.
• There are new default pgh_label values in the new event trackers
• The pghistory.models.Events proxy aggregate model has some minor breaking functionality.

Along with this, default arguments to pghistory.track were changed and a setting was introduced to override the global default history trackers.

There's an entire section called "Upgrading" in the docs at django-pghistory.readthedocs.io that goes over the breaking changes in more detail, along with how to preserve the default functionality from version two.

Support append-only event models [Wesley Kendall, 9002d35]

Supply append_only=True to pghistory.track or pghistory.create_event_model to create event models that protect updates and deletes.

Set settings.PGHISTORY_APPEND_ONLY = True to make this the default for all event models.

Add Python 3.12 support and use Mkdocs for documentation [Wesley Kendall, 4464ef3]

Python 3.12 and Postgres 16 are supported now, along with having revamped docs using Mkdocs and the Material theme.

Python 3.7 support was dropped.

Added Python 3.11, Django 4.2, and Psycopg 3 support [Wesley Kendall, 647cdad]

Adds Python 3.11, Django 4.2, and Psycopg 3 support along with tests for multiple Postgres versions. Drops support for Django 2.2.

Refactory Snapshot class and add Changed condition for better extensibility. [Kevin Ramirez, 0be9242]

Users can more easily inherit pghistory.Snapshot and use the pghistory.Changed condition for conditional snapshots.

Add BeforeUpdateOrDelete tracker [Kevin Ramirez, af01e87]

Adds a barebones BeforeUpdateOrDelete tracker for snapshotting OLD rows during an update or delete.

Fix documentation example for tracking events. [Zac Miller, acaaadf]

Fix bug when tracking context data with percent sign. [Adam Johnson, a5380fa]

All context data is properly escaped, fixing an error that happened when using "%" in any context data. psycopg now escapes all context data, ensuring there is no SQL injection vector in the future.

Ignore tracking non-concrete fields [Wesley Kendall, e7b0589]

If a field isn't concrete, pghistory no longer tries to track it.

Require django-pgtrigger>=4.5 [Wesley Kendall, a70e0d3]

Version 4.5 of django-pgtrigger fixes several bugs related to trigger migrations, especially as they relate to django-pghistory.

See the migration guide to django-pgtrigger version 4 at https://django-pgtrigger.readthedocs.io/en/4.5.3/upgrading.html#version-4. Upgrading from version 3 to 4 only affects mutli-database setups.

Automatically add the "pgh_event_model" attribute to tracked models. [Wesley Kendall, 917c396]

When a model is tracked, a "pgh_event_model" attribute is added to the tracked model to make it easier to inherit the event model and access it.

The label argument for pghistory.track is optional [Wesley Kendall, b6a8c99]

The label argument was previously required. Now it defaults to the name of the tracker.

Simplify conditions for snapshots of all fields [Wesley Kendall, e9dbc06]

Previously when using pghistory.Snapshot, the condition for the trigger would OR together each field to verify nothing changed. Now OLD.* IS DISTINCT FROM NEW.* is used as the condition.

Restructure documentation and add more tests [Wesley Kendall, 3bc868e]

The documemntation was overhauled for the new features and admin integration.

Added reversion capability [Wesley Kendall, c2d8b90]

A revert method was added to event models for reverting changes. The method only runs if the event model tracks every field, otherwise a Runtime error is thrown.

Use ProxyField() for defining proxy columns over attributes. [Wesley Kendall, a267478]

When inheriting the Events model or individual event models, one can use the pghistory.ProxyField utility to proxy relationships from JSON columns into structured fields. For example, making a foreign key for users that proxies through the user attribute of context.

Previously this behavior only worked on the deprecated AggregateEvent model by adding additional fields. Any fields that are proxied must now use the pghistory.ProxyField utility.

Integration with Django admin [Wesley Kendall, a9fea95]

Installing pghistory.admin to settings.INSTALLED_APPS will provide the following:

• An "Events" admin page that other admins can use to display events
• Dynamic buttons on tracked models that redirect to a pre-filtered events admin
• The ability to make admins for specific event models and have them show up as buttons on their associated tracked model admin pages

The default events admin has configuration parameters that can be set via settings.

New event model configuration and new aggregate Events model. [Wes Kendall, c1120f2]

Event models can be configured with global settings and with overrides on a per-event-model basis. Previous arguments to pghistory.track, such as obj_fk and context_fk have been deprecated in place of obj_field and context_field. These new fields, along with their associated settings, use pghistory.Field configuration instances.

Along with this, the AggregateEvent model has been deprecated in favor of the Events proxy model. The new Events model has similar fields and operates the same way, and it also has other methods for filtering aggregate events.

Fix issues related to the dumpdata command [Wes Kendall, 8cb8036]

Django's dumpdata command is now compatible with pghistory's AggregateEvent model.

Check that "pgtrigger" is in settings.INSTALLED_APPS [Wes Kendall, fa86205]

A check is registered with Django's check framework to verify that "pgtrigger" is in settings.INSTALLED_APPS when using django-pghistory.

Docs were also updated to note the requirement of pgtrigger in INSTALLED_APPS.

Install context tracking function in a migration [Wes Kendall, 516dc14]

The Postgres pghistory function is now installed in a migration, alleviating issues that would happen when trying to migrate pghistory triggers.

Configure middleware tracked methods [Wes Kendall, e931757]

Use settings.PGHISTORY_MIDDLEWARE_METHODS to configure which methods are tracked in the middleware. Defaults to ("GET", "POST", "PUT", "PATCH", "DELETE").

Add setting to configure JSON encoder for context. [Zac Miller, 430225f]

django-pghistory now uses Django's default JSON encoder to serialize contexts, which supports datetimes, UUIDs, and other fields.

You can override the JSON encoder by setting PGHISTORY_JSON_ENCODER to the path of the class.

Integration with Django's migration system [Wes Kendall, e0acead]

django-pghistory upgrades django-pgtrigger, which now integrates with the Django migration system.

Run python manage.py makemigrations to make migrations for the triggers created by django-pghistory in order to upgrade.

If you are tracking changes to third-party models, register the tracker on a proxy model so that migrations are created in the proper app.

Remove dependency on django-pgconnection [Wes Kendall, aea6056]

django-pghistory no longer requires that users wrap settings.DATABASES with django-pgconnection.

Add support for GET requests in pghistory middleware [Shivananda Sahu, ae2524e]

Currently the middleware adds a context for POST, PUT, PATCH and DELETE requests. Updating middleware to add a context for GET requests along with POST, PUT, PATCH and DELETE.

Allow target() to receive a queryset or list. [M Somerville, 0f34e91]

This expands the target() function to accept a queryset or a list of objects on top of the existing one object.

Add support for delete requests in pghistory middleware [Shivananda Sahu, 322d17e]

Currently the middleware adds a context for POST, PUT, and PATCH requests. This leaves out DELETE requests as the only ones that can affect a model without a context. Updating middleware to add a context for DELETE requests along with POST, PUT and PATCH.

Fixed bug in BeforeDelete event [Wes Kendall, aab4182]

The BeforeDelete event was referencing the wrong trigger value (NEW). Code was updated to reference the proper OLD row for this event, and a failing test case was added.

Upgrade pgtrigger and test against Django 3.1 [Wes Kendall, 176fb13]

Uses the latest version of django-pgtrigger. Also tests against Django 3.1 and fixes a few bugs related to internal changes in the Django codebase.

Escape single quotes in tracked context [Wes Kendall, 40f758e]

Invalid SQL was generated from context values with single quotes when using pghistory.context. Single quotes are now properly escaped, and a failing test case was created to cover this scenario.

Initial release of django-pghistory. [Wes Kendall, ecfcf96]

django-pghistory provides automated and customizable history tracking for Django models using Postgres triggers. Users can configure a number of event trackers to snapshot every model change or to fire specific events when certain changes occur in the database.

In contrast with other Django auditing and history tracking apps (seen here), django-pghistory has the following advantages:

1. No instrumentation of model and queryset methods in order to properly track history. After configuring your model, events will be tracked automatically with no other changes to code. In contrast with apps like django-reversion, it is impossible for code to accidentally bypass history tracking, and users do not have to use a specific model/queryset interface to ensure history is correctly tracked.
2. Bulk updates and all other modifications to the database that do not fire Django signals will still be properly tracked.
3. Historical event modeling is completely controlled by the user and kept in sync with models being tracked. There are no cumbersome generic foreign keys and little dependence on unstructured JSON fields for tracking changes, making it easier to use the historical events in your application (and in a performant manner).
4. Changes to multiple objects in a request (or any level of granularity) can be grouped together under the same context. Although history tracking happens in Postgres triggers, application code can still attach metadata to historical events, such as the URL of the request, leading to a more clear and useful audit trail.