Closed BonaFideIT0 closed 9 months ago
Can you give a minimal repro?
Could be, that the graph construction needs another explicit modelname to model type resolve step, but I am not sure yet, where the twist is - it seems, that the models worked on in the loop here still contains the str-notion: https://github.com/netzkolchose/django-computedfields/blob/e9985a6d0458753c0ac9aa1a90d97b8234a5e7da/computedfields/graph.py#L496
On a second glance - technically this should not have happened, as the resolver/graph always works on model types, never on the str-versions (pulled from model init signals). So yeah a repro would be good to check, where it breaks with that assumption.
Edit: I think I've found the culprit here: https://github.com/netzkolchose/django-computedfields/blob/e9985a6d0458753c0ac9aa1a90d97b8234a5e7da/computedfields/graph.py#L580
This indeed pulls the to
value of the fk field without further check, which still contains the str version. Not sure yet, if thats easy fixable, the code at that stage kinda relies on proper model resolution already done by django.
Cannot repro with the minimal example (tested with python 3.10, django 4.2):
class FkIssue(ComputedFieldsModel):
fieldname = models.ForeignKey('FkOther', on_delete=models.CASCADE)
@computed(models.IntegerField(), depends=[('fieldname', ['aa'])])
def pulled_aa(self):
return self.fieldname.aa
class FkOther(models.Model):
aa = models.IntegerField()
The models are already loaded properly and related_model
returns a model type, not a str for fieldname
(from debug log):
model: <class 'test_full.models.FkIssue'>
symbol: fieldname cls: <class 'test_full.models.FkOther'>
Plz provide the following info:
Hi Jerch,
thanks for your effort so far, I will have time to create a minimal repo the next few days and will get back to you. :)
cheers
Hi there,
when using a String reference to a model from another app like this on a ComputedFieldModel:
fieldname = models.ForeignKey("appname.ModelName")
we get this error:
Upon further investigation we get that "model" (in the above snippet) contains the string reference to the model like this:
"appname.ModelName"
This might be happening due to usage of PEP-563 (https://peps.python.org/pep-0563/) style type hints, but I suspect (havent checked yet) this is due to missing model name resolution at this point.
After trying a few techniques for resolving the model that early before registry initialization I concede that fixing this might be beyond my current understanding of the problem.
Would you kindly look into it? It would help massively with a circular dependency problem we are having right now. ;)
Sincere thanks for your great work!