refresh_from_db RecursionError

[devxplorer]

We have a case where we need to track the status change on the model. This is done by assigning an current status attribute in the init method.

In tests in many places we use the refresh_from_db method, together all these things give an error with recursion.

To illustrate the error, a simple project was created: https://github.com/devxplorer/onchange

I'm not sure if this can be considered a bug, but I have not come up with the problem yet.

[vdboor]

Thanks for giving such nice example! This is something that clearly needs to be fixed.

[AndySun25]

We had a similar issue to this a while back, using https://django-model-utils.readthedocs.io/en/latest/utilities.html#field-tracker ultimately ended up fixing the issue for us.

Perhaps it could be of use.

[devxplorer]

@AndySun25 Thank you for your comment, I'll try your solution when I have the opportunity

[Vader19695]

Is there any update on this issue?

[nanorepublica]

I am starting to hit this issue (using the model utils FieldTracker) when upgrading to the following versions:

• Django 3.2
• Django-polymorphic 3.1.0
• Django model utils 4.2.0

Definitely happy to help find a fix

[GuerrettaG]

Hi, just wanted to say that we were facing the same issue, but I couldn't reproduce locally until I set settings.DISABLE_SERVER_SIDE_SETTINGS=True for our postgres DB. With settings.DISABLE_SERVER_SIDE_SETTINGS=False I wasn't getting the error.

[Gartosz]

@GuerrettaG could you please elaborate further? I cannot find such setting as DISABLE_SERVER_SIDE_SETTINGS neither in Django, nor in postgres. What versions are you using?

[GuerrettaG]

Hi, seems like 2y ago I made a mistake, what I was referring to was DISABLE_SERVER_SIDE_CURSORS https://docs.djangoproject.com/en/5.1/ref/settings/#disable-server-side-cursors

[bckohan]

Here's whats happening:

1. refresh_from_db will use the _base_manager (which is a PolymorphicManager) to fetch a new instance of the model from the db.
2. Polymorphic managers will attempt to downcast the objects after the initial fetch in a 2-step process based on the content type id.
3. Because you've passed fields=('status',) the polymorphic_ctype_id will not be fetched but in the second phase of the process it is accessed to check for downcastability which triggers a deferred load using the same queryset which is tagged with the only fields and hence the infinite recursion.

The following code from your example will work:

draft = Status.objects.create(name='draft')
closed = Status.objects.create(name='closed')

item = Item.objects.create(status=draft)
Item.objects.filter(id=item.id).update(status=closed)
item.refresh_from_db(fields=('status', 'polymorphic_ctype_id'))  # <-- add the ctype id

I'm going to accept this as a bug on the library. polymorphic_ctype_id is so foundational to how the extended querysets work that I think it should automatically be added to the fields listed in only() just as vanilla Django does automatically with the primary key fields.