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 django-users+unsubscr...@googlegroups.com.
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 django-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/b07189e4-d38e-1832-7b90-a439722625f0%40fattuba.com.
