v1.0a1 serializes additional_data log entry field as string

After upgrading Django from 2.2 to 3.1.1 and django-auditlog from 0.4.7 to v1.0a1 I now have to json.loads(log_entry["additional_data"]) to get the same result as log_entry["additional_data"] before. Is this an intentional change?

Also, django 3.1 has a built-in JSONField which we’d probably want to use when available.

[chrisittner]

What is the status on this and https://github.com/jazzband/django-auditlog/pull/271? I looked through the issues and this appears to me to be the only blocker for releasing a stable 1.0 version on pypi? While this issue is important, so is keeping up to date with the mainstream Django version and the latest stable release of django-auditlog supports neither 3.0 nor 3.1. It would be great to resolve this quickly and to get django-auditlog compatible with mainstream Django 3.1. I’d be happy to contribute a patch if you point me in the right direction and there is a chance for it to get merged.

IMO it’s unavoidable to move away from django-jsonfield (as that one won’t get 3.1 compatibility) and, as stated above, there are two options:

• leave the additional_data format unchanged on db level, by switching from jsonfield.JSONField to models.TextField and pull (de-)serialization into django auditlog. Admittedly a slight degradation, but does the job.
• migrate to django-jsonfield-backport and the new JSONField for 3.1+. This has the downside of requiring a migration on LogEntry, just for keeping the non-essential additional_data field compatible.

Either route is fine, but since additional_data is not a central feature of auditlog, it seems sensible to first change it to a TextField with manual json handling, just to kill the django-jsonfield dependency and to get a released django-auditlog that is compatible with both mainstream (3.1) and LTS Django (2.2).

In a later release, the LogEntry model can be migrated to benefit from the new models.JSONField on all relevant fields (changes, additional_data,…), along with dropping Django 2.2./3.0 support for that new release.

[eprikazc]

@jezdez @chrisittner are you guys aware that for Postgres db django-jsonfield creates jsonb field ? https://github.com/adamchainz/django-jsonfield/blame/master/jsonfield/fields.py#L75 i.e. no matter if we change additional_data to TextField or to django JSONField, some databases will be affected and db migration will be needed anyway.

To me switching to JSONField looks like a natural choice going forward. Most databases and Django now support JSONField out of the box and it is handy for querying data inside of it. I understand the concern of having to do potentially lengthy migration, though. I am wondering if it would make sense to avoid it. For example, we could try to make a migration with 2 actions:

• rename column additional_data => additional_data_old
• create a new nullable JSON column named additional_data

additional_data_old would be only in migration, not in LogEntry model. I assume Django allows to craft such migration. This way no data migration will be performed, yet all old data would still be available, and people could decide by themselves if they want to copy data from additional_data_old to additional_data column, or just drop additional_data_old. Or they can just stick to using older version of django-auditlog. Seems like a good compromise to move the project forward. If you guys ok with the idea, I am happy to prepare a PR.