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.
