Since this is a question about your models, please post your models.py.
On 7/27/22 5:18 AM, Malik Rumi wrote:
I have a model with a recursive foreign key to 'self'. This is
intended to model a parent child
relation among instances. The forward relation, on a field called
'childof', works as expected.
The reverse relation, using the related_name 'parent', comes up as a
RelatedManager,
again as expected. However, parent.count(), parent.all(), etc., always
give me the "Manager is
not accessible on instances" error. Many of these parent instances
will themselves also be a
childof some other instance, and apparently, that's my problem. I
don't know how to make Django
recognize the dual nature of some instances. Is there a way to hack
the RelatedManager to fix this?
I am not getting any accessor errors from manage.py check.
I posted this to Django Forum, but the respondent was not able to
duplicate my issue - i.e.,
he said it worked as expected for him. :-(
I saw a suggestion to use an explicit junction table on Stack
Overflow, but making a round trip - or two - to an external table
seems like an
awful lot of overhead for this situation.
If instead of a junction table, if I made an explicit parentto field
on the model, would that work?
Presumably the related name on the childof field would still fail like
it does now,
but I would instead have the explicit parent field to work with. I
still would not have the
automatic reverse relation, and I would have to come up with a script
to fill in the parentto
field, but that might solve my problem:
# pseudocode
family = c.itertools.groupby(instance.childof)
family = c.pandas.groupby(instance.childof)
for f in family:
pop = c.objects.get(instance.childof)
OR
pop = instance.childof
c.objects.update(pop.parentto=f) # where parentto is a Postgresql
ArrayField
OR #
https://docs.djangoproject.com/en/4.0/ref/models/relations/#django.db.models
.fields.related.RelatedManager.add:
>>> b = Blog.objects.get(id=1)
>>> e = Entry.objects.get(id=234)
>>> b.entry_set.add(e) # Associates Entry e with Blog b
SEE ALSO:
https://docs.djangoproject.com/en/4.0/topics/db/examples/many_to_one/
If I did this two field hack, then I don't really need either one to
be ForeignKeys any more,
do I? They could be a CharField and an ArrayField, couldn't they? That
breaks the extended
lookup chain - but I don't have that now, anyway - or at least, I only
have it in one direction.
--
You received this message because you are subscribed to the Google
Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/3555d391-9c9e-440f-a603-103c9ccdc858n%40googlegroups.com
<https://groups.google.com/d/msgid/django-users/3555d391-9c9e-440f-a603-103c9ccdc858n%40googlegroups.com?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google Groups "Django
users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/b07189e4-d38e-1832-7b90-a439722625f0%40fattuba.com.
