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
-~----------~----~----~----~------~----~------~--~---
