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.
