Release Notes¶
3.5.4 (2025-03-12)¶
Changes¶
3.5.3 (2025-02-27)¶
Fixes¶
- Fix custom field support by deconstructing field classes correctly in history model by @iamsauravsharma in #184.
3.5.2 (2025-02-05)¶
Changes¶
- Ignore
testcommand when tracking context @iamsauravsharma in #180.
3.5.1 (2024-12-15)¶
Changes¶
- Changed project ownership to
AmbitionEngby @wesleykendall in #180.
3.5.0 (2024-11-01)¶
Features¶
- Optimized
Eventsdiff queries by ~100x via a subquery instead ofLAGwindows by @lokhman in #173. - Optimized object-level
Eventsqueries in the django admin by avoidingUNIONqueries by @lokhman in #174.
Changes¶
- Added Python 3.13 support, dropped Python 3.8. Added Postgres17 support by @wesleykendall in #175.
3.4.4 (2024-09-27)¶
Fixes¶
3.4.3 (2024-09-14)¶
Fixes¶
- Add missing py.typed file by @max-muoto in #166.
3.4.2 (2024-09-10)¶
Fixes¶
- Fix using
@pghistory.track()on models that have concrete inheritance by @wesleykendall in #164.
3.4.1 (2024-09-06)¶
Fixes¶
- The
related_query_namesetting for tracked foreign keys had the default value mistakenly changed in v3.4.0. Fixed by @wesleykendall in #163.
3.4.0 (2024-09-02)¶
Features¶
-
Make context middleware extensible by @wesleykendall in #141.
Inherit
pghistory.context.HistoryMiddlewareand overrideget_contextto add additional context data for every request. -
Support offline documentation formats by @wesleykendall in #144.
PDF versions of documentation are built via ReadTheDocs.
Fixes¶
- Check that the execute result is not
Nonebefore trying to accessexecute_result.nextset()by @wesleykendall in #156. - Ensure
pghistory.create_eventworks when using denormalized context by @wesleykendall in #154. - More accurate type hints for the public interface by @wesleykendall in #143.
- Fix minor docstring issue in
pghistory.create_event_modelby @wesleykendall in #148.
Documentation¶
- Clean up configuration section of docs, ensure all settings are documented by @wesleykendall in #142.
- Modify conditional tracking examples by @wesleykendall in #145.
- Add section to FAQ on backfilling data by @wesleykendall in #146.
- Adjust guide on tracking management commands by @wesleykendall in #150.
- Note the Q/A discussions in the FAQ by @wesleykendall in #152.
3.3.0 (2024-08-27)¶
Features¶
PGHISTORY_INSTALL_CONTEXT_FUNC_ON_MIGRATEsetting to configure installation of tracking function after migrations by @wesleykendall in #140.PGHISTORY_CREATED_AT_FUNCTIONsetting to configure the function for determining the current time in history triggers by @lokhman in #137.- Add ASGI support by @pablogadhi in #127.
Fixes¶
-
Ensure
BigAutoFields are properly mirrored in history models by @tobiasmcnulty in #134.Warning
If you have event models for models with
BigAutoFieldprimary keys, you will see new migrations to convertpgh_obj_idto a bigint. -
Support filtering event models by referenced proxy models by @lokhman in #135.
- Ensure
bytesrepresentations of SQL are handled by @tobiasmcnulty in #136. - Fix setting default trackers with the
PGHISTORY_DEFAULT_TRACKERSsetting by @SupImDos in #133. - Don't install pghistory's context tracking function on non-postgres databases by @pmdevita in #132.
- Ensure
MiddlewareEventsdoesn't filter out non-middleware events in the admin by @lokhman in #130. - Support custom primary keys for the aggregate
Eventsproxy model by @lokhman in #128. - Fix type hints for
pghistory.trackby @SebastianDix in #118[https://github.com/Opus10/django-pghistory/pull/118]. - Support named arguments in SQL by (@foobarna)[https://github.com/foobarna] in (#111)[https://github.com/Opus10/django-pghistory/pull/111].
Changes¶
- Django 5.1 compatibility, dropped Django 3.2 / Postgres 12 support by @wesleykendall in #139.
- Added section in FAQ for handling issues with concrete inheritance by @xaitec in #138.
- Add reference to DjangoCon talk in the docs by @max-muoto in #114.
3.2.0 (2024-04-20)¶
Bug¶
-
Fix Empty List being passed into create_event_model [Maxwell Muoto, b89c86d]
Fix Empty List being passed into create_event_model
3.1.1 (2024-04-06)¶
Trivial¶
- Fix ReadTheDocs builds. [Wesley Kendall, eda0741]
3.1.0 (2023-11-26)¶
Feature¶
-
Django 5.0 compatibility [Wesley Kendall, 934ca6d]
Support and test against Django 5 with psycopg2 and psycopg3.
3.0.1 (2023-10-16)¶
Trivial¶
- Add upgrading notes around the default related name changing. [Wesley Kendall, c5d8a1f]
3.0.0 (2023-10-16)¶
Api-Break¶
-
V3 release with new event trackers [Wesley Kendall, 8849fc6]
Version three of
django-pghistoryhas 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.Snapshotand all custom event trackers such aspghistory.BeforeDeleteandpghistory.AfterInsertOrUpdatewere consolidated into three core event trackers:pghistory.InsertEvent,pghistory.UpdateEvent, andpghistory.DeleteEvent. - There are new default
pgh_labelvalues in the new event trackers - The
pghistory.models.Eventsproxy aggregate model has some minor breaking functionality.
Along with this, default arguments to
pghistory.trackwere 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.
Feature¶
-
Support append-only event models [Wesley Kendall, 9002d35]
Supply
append_only=Truetopghistory.trackorpghistory.create_event_modelto create event models that protect updates and deletes.Set
settings.PGHISTORY_APPEND_ONLY = Trueto make this the default for all event models.
2.9.0 (2023-10-09)¶
Feature¶
-
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.
2.8.0 (2023-06-08)¶
Feature¶
-
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.
2.7.0 (2023-04-08)¶
Feature¶
-
Refactory
Snapshotclass and addChangedcondition for better extensibility. [Kevin Ramirez, 0be9242]Users can more easily inherit
pghistory.Snapshotand use thepghistory.Changedcondition for conditional snapshots. - AddBeforeUpdateOrDeletetracker [Kevin Ramirez, af01e87]Adds a barebones
BeforeUpdateOrDeletetracker for snapshotting OLD rows during an update or delete.
Trivial¶
- Fix auto-doc formatting [madtools, de3ddf4]
2.6.0 (2023-03-27)¶
Bug¶
- 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.
Trivial¶
- Replace usage of
SET LOCALwithSELECT set_configfor better pg stat reporting. [Pierre Ducroquet, ebe2d19] - Fix
make lintcommand with new .gitignore changes [Kevin Ramirez, ceafe0a] - Fix
PGHISTORY_OBJ_FIELDsettings name in the docs. [Johan Van de Wauw, 2bfb23d] - Updated with latest django template, fixing git-tidy deployment issues [Wesley Kendall, 1a6df96]
2.5.1 (2022-10-12)¶
Trivial¶
- Updated with latest Django template [Wesley Kendall, de8a535]
- A safer way of determining fields when creating the snapshot triggers [Wesley Kendall, 7b368c3]
2.5.0 (2022-10-11)¶
Bug¶
-
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-pgtriggerfixes several bugs related to trigger migrations, especially as they relate todjango-pghistory.See the migration guide to
django-pgtriggerversion 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.
Feature¶
-
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.trackis 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. NowOLD.* 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
revertmethod was added to event models for reverting changes. The method only runs if the event model tracks every field, otherwise aRuntimeerror is thrown. - Use ProxyField() for defining proxy columns over attributes. [Wesley Kendall, a267478]When inheriting the
Eventsmodel or individual event models, one can use thepghistory.ProxyFieldutility to proxy relationships from JSON columns into structured fields. For example, making a foreign key for users that proxies through theuserattribute of context.Previously this behavior only worked on the deprecated
AggregateEventmodel by adding additional fields. Any fields that are proxied must now use thepghistory.ProxyFieldutility. - Integration with Django admin [Wesley Kendall, a9fea95]Installing
pghistory.admintosettings.INSTALLED_APPSwill 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
Eventsmodel. [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 asobj_fkandcontext_fkhave been deprecated in place ofobj_fieldandcontext_field. These new fields, along with their associated settings, usepghistory.Fieldconfiguration instances.Along with this, the
AggregateEventmodel has been deprecated in favor of theEventsproxy model. The newEventsmodel has similar fields and operates the same way, and it also has other methods for filtering aggregate events.
Trivial¶
- Rename "tracking" module to "runtime" module. [Wesley Kendall, 43645ea]
2.4.2 (2022-10-06)¶
Trivial¶
- Update with the latest Python template [Wesley Kendall, ef2fb6e]
2.4.1 (2022-09-13)¶
Trivial¶
- Ensure installation of pghistory context function is installed across multiple databases [Wes Kendall, d06c758]
2.4.0 (2022-09-07)¶
Bug¶
-
Fix issues related to the
dumpdatacommand [Wes Kendall, 8cb8036]Django's
dumpdatacommand is now compatible with pghistory's AggregateEvent model.
2.3.0 (2022-09-06)¶
Bug¶
-
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.
2.2.2 (2022-09-02)¶
Trivial¶
- Reference PK of user instead of ID in middleware for DRF-based flows [Wes Kendall, 2193e2b]
2.2.1 (2022-09-02)¶
Trivial¶
- Do additional safety checks in middleware [Wes Kendall, 9678d83]
2.2.0 (2022-09-02)¶
Feature¶
-
Configure middleware tracked methods [Wes Kendall, e931757]
Use
settings.PGHISTORY_MIDDLEWARE_METHODSto configure which methods are tracked in the middleware. Defaults to("GET", "POST", "PUT", "PATCH", "DELETE").
2.1.1 (2022-08-31)¶
Trivial¶
- Format trigger SQL for better compatibility with
django-pgtrigger>=4.5 [Wes Kendall, fa04191]
2.1.0 (2022-08-27)¶
Feature¶
-
Add setting to configure JSON encoder for context. [Zac Miller, 430225f]
django-pghistorynow 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_ENCODERto the path of the class.
Trivial¶
- Local development enhancements [Wes Kendall, 95a5b1d]
2.0.3 (2022-08-26)¶
Trivial¶
- Test against Django 4.1 and other CI improvements [Wes Kendall, 953fe1d]
2.0.2 (2022-08-24)¶
Trivial¶
- Fix ReadTheDocs builds [Wes Kendall, afbc33e]
2.0.1 (2022-08-20)¶
Trivial¶
- Fix release note rendering and code formatting changes [Wes Kendall, 7043553]
2.0.0 (2022-08-08)¶
Api-Break¶
-
Integration with Django's migration system [Wes Kendall, e0acead]
django-pghistoryupgradesdjango-pgtrigger, which now integrates with the Django migration system.Run
python manage.py makemigrationsto make migrations for the triggers created bydjango-pghistoryin 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.
Feature¶
-
Remove dependency on
django-pgconnection[Wes Kendall, aea6056]django-pghistoryno longer requires that users wrapsettings.DATABASESwithdjango-pgconnection.
1.5.2 (2022-07-31)¶
Trivial¶
- Updated with latest Django template, fixing doc builds [Wes Kendall, 42cbc3c]
1.5.1 (2022-07-31)¶
Trivial¶
- Use
pkinstead ofidto get the user's primary key [Eerik Sven Puudist, f105828] - Fix default_app_config warning on Django 3.2+ [Adam Johnson, 8753bc4]
1.5.0 (2022-05-17)¶
Feature¶
-
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.
1.4.0 (2022-03-13)¶
Feature¶
-
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.
Trivial¶
- Minor code formatting fixes [Wes Kendall, d0b7664]
1.3.0 (2022-03-13)¶
Bug¶
-
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.
1.2.2 (2022-03-13)¶
Trivial¶
- Updated with latest template, dropping 3.6 support and adding Django 4 support [Wes Kendall, c160973]
1.2.1 (2021-05-30)¶
Trivial¶
- Updated with latest python template [Wes Kendall, 09f6cfb]
1.2.0 (2020-10-23)¶
Feature¶
-
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.
1.1.0 (2020-08-04)¶
Bug¶
-
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.
1.0.1 (2020-06-29)¶
Trivial¶
- Updated with the latest public django app template. [Wes Kendall, fc1f3e4]
1.0.0 (2020-06-27)¶
Api-Break¶
-
Initial release of django-pghistory. [Wes Kendall, ecfcf96]
django-pghistoryprovides 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-pghistoryhas the following advantages:- 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.
- Bulk updates and all other modifications to the database that do not fire Django signals will still be properly tracked.
- 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).
- 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.