Support for string representation of foreign key changes

[fabianallendorf]

With PR #420, the handling of changes in foreign key relationships has been updated. Instead of storing the string representation of the related object, the primary key values are now stored. Additionally, displaying such changes now requires database queries, as reflected in the updated LogEntry.changes_display_dict method.

Before:

{ "foreign_key_field": ["foo", "bar"] }

After:

{ "foreign_key_field": [1, 2] }

While this change makes sense, it makes upgrading to v3 more challenging in my case. I manually parse change data to display it to users. Additionally this new behavior introduces performance concerns. Specifically, fetching related objects for each changed foreign key field results in additional database roundtrips, which were not previously necessary.

To address this, I’d like to propose introducing a setting, such as USE_STRING_REPRESENTATION_FOR_FOREIGN_KEY_CHANGES (defaulting to False). This would allow projects like mine to retain the previous behavior and simplify the upgrade process to v3.

If this sounds acceptable, I’d be happy to prepare a PR to implement this change, as it shouldn’t be too complex.

[hramezani]

Thanks @fabianallendorf for this issue.

Good idea, go for it