You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have another model Bar with a ForeignKey to Foo,
This ForeignKey has a related_query_name set to bar,
We register Bar with django-simple-history.
Then, both the initial and the historical model (Bar and HistoricalBar) use the same related_query_name. In other terms, queries like Foo.objects.filter(bar__isnull=False).count() might return inconsistent and unexpected results, getting the models Bar and HistoricalBar mixed up. In some similar cases, the initial reverse relation takes a back seat to the historical one.
To Reproduce
This repository contains a minimal reproducible example. In particular, see the models.py file with the set up described above and the initial migration file. Lines 58 and 97 of this migration file are commented to highlight the problem.
Expected behavior
Admittedly, it's recommended to use %(class)s in the related_query_name to avoid conflicts. But when this precaution is not taken, I think that either an error should be raised, or the default ForeignKey.related_query_name of an HistoricalModel should be something like historical_[initial_related_query_name], in order not to overwrite the initial reverse relation. The current behavior can lead to pesky bugs...
As a reminder, in similar situations, Django sometimes raises an exception fields.E305 (see here).
Screenshots
Environment
Django Simple History Version: 3.4.0
Django Version: 4.2.7
The text was updated successfully, but these errors were encountered:
Describe the bug
Let's assume that:
Foo
,Bar
with aForeignKey
toFoo
,ForeignKey
has arelated_query_name
set tobar
,Bar
withdjango-simple-history
.Then, both the initial and the historical model (
Bar
andHistoricalBar
) use the samerelated_query_name
. In other terms, queries likeFoo.objects.filter(bar__isnull=False).count()
might return inconsistent and unexpected results, getting the modelsBar
andHistoricalBar
mixed up. In some similar cases, the initial reverse relation takes a back seat to the historical one.To Reproduce
This repository contains a minimal reproducible example. In particular, see the models.py file with the set up described above and the initial migration file. Lines 58 and 97 of this migration file are commented to highlight the problem.
Expected behavior
Admittedly, it's recommended to use
%(class)s
in therelated_query_name
to avoid conflicts. But when this precaution is not taken, I think that either an error should be raised, or the defaultForeignKey.related_query_name
of anHistoricalModel
should be something likehistorical_[initial_related_query_name]
, in order not to overwrite the initial reverse relation. The current behavior can lead to pesky bugs...As a reminder, in similar situations, Django sometimes raises an exception
fields.E305
(see here).Screenshots
Environment
The text was updated successfully, but these errors were encountered: