Using many to many relationship will work better. Nice note ๐ค Your quote Translation : "ูุง ูุคู ู ุงุญุฏูู ุญุชู ูุญุจ ูุงุฎูู ู ุง ูุญุจ ูููุณู" On 27 Jul 2022 19:04, "Malik Rumi" <malik.a.r...@gmail.com> wrote:
> Thanks, but the recursive foreignkey *is* a one to many relationship... > unless you're talking about something else? > *โNone of you has faith until he loves for his brother or his neighbor > what he loves for himself.โ* > > > On Wed, Jul 27, 2022 at 10:16 AM Ammar Mohammed <amarben1...@gmail.com> > wrote: > >> Hi >> Have you tried using OneToMany relationship ? >> On 27 Jul 2022 12:18, "Malik Rumi" <malik.a.r...@gmail.com> 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 a topic in the >> Google Groups "Django users" group. >> To unsubscribe from this topic, visit https://groups.google.com/d/ >> topic/django-users/xGtwxhx2Nrw/unsubscribe. >> To unsubscribe from this group and all its topics, 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/CAHs1H7tjom_GRucP8Dx3x8AzQobS4GCva8a0nuN3b >> EWVB2Taqw%40mail.gmail.com >> <https://groups.google.com/d/msgid/django-users/CAHs1H7tjom_GRucP8Dx3x8AzQobS4GCva8a0nuN3bEWVB2Taqw%40mail.gmail.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/CAKd6oBxYfR6ntzGe8EGbnm0z6%2BxjiJDP5nmg9kF5kuB9pCZiEg% > 40mail.gmail.com > <https://groups.google.com/d/msgid/django-users/CAKd6oBxYfR6ntzGe8EGbnm0z6%2BxjiJDP5nmg9kF5kuB9pCZiEg%40mail.gmail.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/CAHs1H7sLom%3DupzWEEt2X%2BYz2GPHdOb7zvawH5DqUkyoqk2XYjg%40mail.gmail.com.
