On Wed, Jan 21, 2009 at 7:27 PM, Mackenzie Kearl <macken...@definitionsystems.ca> wrote: > > On Jan 21, 11:14 am, Aneurin Price <aneurin.pr...@gmail.com> wrote: >> (Apologies for the vague subject; I couldn't think how to summarise this :P) >> >> Hello all, >> >> I have an application where some models are inherited from others, like so: >> Foo >> / \ >> Bar Baz >> Each object has (or may have) a parent object, which is a Foo (it might be a >> Bar >> or a Baz, or some other subclass, but it's definitely a Foo). I'd like to be >> able to find the children of an object, both overall and by subclass, using >> 'foo_object.children.all()', or 'foo_object.bars.all()' and so on. >> >> Originally I set up parent links in Foo, as something like >> "parent=models.ForeignKey('self', related_name='children')", but when I >> realised >> that I mostly want to get the children in groups, I changed the way I was >> doing >> this. Now I have per-class links like "parent=models.ForeignKey('Foo', >> related_name='bars')", etc. This allows me to have the parent/child hierarchy >> that I want, and access the children in the appropriate groups, but it feels >> rathr ugly, and I'd still like an aggregate 'children' set so that I don't >> have >> to use each set individually (and update every use if I ever add new >> subclasses). >> >> Additionally, I don't know if I'll need this, but I'm interested in how I >> might >> get a link to 'children_of_same_type', so in Foo it would be an alias to >> 'children', but in Bar it would be an alias to 'bars', etc. I can't just do >> 'children_of_same_type = bars' because 'bars' is autogenerated so hasn't been >> defined yet. >> >> I hope that makes sense, but if not I can come up with a few more examples to >> try to clarify it. >> >> Does anybody have any suggestions as to how I should structure this? Would I >> be >> best to leave the parent links as they are and define custom Managers for >> 'children' and 'children_of_same_type'? If so, pointers on how to go about >> this >> would be appreciated. >> >> Thanks, >> Nye > > Why don't you instead of subclass Foo just create a foreignkey to Foo > or a OneToOne with foo. > > 'foo_object.children.all()' > I don't think that this is possible because it contains different > models in the query. > > The other option that you could try is a generic relation something > like the way django-tagging works. > > I hope this is a help >
It occurred to me last night that I could get the behaviour I want rather more simply. I've now gone back to using "parent=models.ForeignKey('self', related_name='children')" in Foo, and added a couple of properties for the rest like so: @property def bars(self): return Bar.objects.get_query_set().filter(parent=self) One thing I'm unsure about here is the get_query_set() - Ive used it because all the examples I've seen doing something similar have used it, but so far as I can tell the result is exactly the same as Bar.objects.filter(parent=self). Could somebody en;ighten me here? This approach can't handle the children_of_same_type case, but it's a start. Unfortunately it appears that the ORM doesn't provide any real polymorphism for models, so I may have to rethink what I'm doing anyway. I'm beginning to think I may be trying to write C++ in Python... Actually, part of what I want to do is covered by this: http://lazypython.blogspot.com/2008/11/timeline-view-in-django.html So I've got a lot to think about. Thanks, Nye --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---