* Modify ``change`` field to be a json field.
Storing the object changes as a json is preferred because it allows SQL
queries to access the change values. This work moves the burden of
handling json objects from an implementation of python's json library in
this package and puts it instead onto the ORM. Ultimately, having the
text field store the changes was leaving them less accessible to external
systems and code that is written outside the scope of the django
auditlog.
This change was accomplished by updating the field type on the model and
then removing the JSON dumps invocations on write and JSON loads
invocations on read. Test were updated to assert equality of
dictionaries rather than equality of JSON parsable text.
Separately, it was asserted that postgres will make these changes to
existing data. Therefore, existing postgres installations should update the
type of existing field values without issue.
* Add test coverage for messages exceeding char len
The "Modify change field to be a json field" commit reduced test
coverage on the mixins.py file by 0.03%. The reduction in coverage was
the result of reducing the number of operations required to achieve the
desired state. An additional test was added to increase previously
uncovered code. The net effect is an increase in test case coverage.
* Add line to changelog
Better markdown formatting
Co-authored-by: Hasan Ramezani <hasan.r67@gmail.com>
* Update CHANGELOG text format
More specific language in the improvement section regarding `LogEntry.change`
Co-authored-by: Hasan Ramezani <hasan.r67@gmail.com>
* Update migration to show Django version 4.0
Co-authored-by: Hasan Ramezani <hasan.r67@gmail.com>
* Update CHANGELOG to show breaking change
Running the migration to update the field type of `LogEntry.change` is a breaking change.
Co-authored-by: Hasan Ramezani <hasan.r67@gmail.com>
* Update serial order of migrations
* Adjust manager method for compatibility
The create log method on the LogEntry manager required an additional
kwarg for a call to create an instance regardless of a change or not.
This felt brittle anyway. The reason it had worked prior to these
changes was that the `change` kwarg was sending a string "null" and
not a None when there were no changes.
Co-authored-by: Hasan Ramezani <hasan.r67@gmail.com>
This is a breaking change. The default behavior is to delete the
related objects, but it doesn't make sense to apply it to audit log
entries, at least not by default.
Many queries, including the default ordering, for the LogEntry
model rely on the timestamp field. Adding an index will ensure
reasonable scalability for large audit logs.
* enable use of replica database
When you use replica database the django-auditlog try to write in the same database where object was read (replica). But this is a read only database and crash the application.
This changes saves always in the default database.
If you want to save in multiple databases or in a special one use `DATABASE_ROUTERS` to configure it.
Co-authored-by: Hasan Ramezani <hasan.r67@gmail.com>
The `django-jsonfield` module is not maintained anymore and raises some
errors with Django 4.0. So, as a recommendation in this package, and as
Django 2.2 is still maintained, `django-jsonfield-backport` will do the
job for the `JSONField` field.
Ref #43
Ref #334
For some applications the possibility to filter by the `action` field might be really interesting. However the lack of an index can lead to severe reduction of such queries.
The simplest solution: Let's a DB index on that field :)
The `django-jsonfield` module is not maintained anymore and raises some
errors with Django 4.0. So, as a recommendation in this package, and as
Django 2.2 is still maintained, `django-jsonfield-backport` will do the
job for the `JSONField` field.
Ref #43
Ref #334
For some applications the possibility to filter by the `action` field might be really interesting. However the lack of an index can lead to severe reduction of such queries.
The simplest solution: Let's a DB index on that field :)
