Hi Kip,

Thanks for your help with this. :)

MTI is meant to be Multi-Table Inheritance, sorry. I copied the
reference from other Django related docs. :)


About using that generic_relations example, it's hard to explain
without diagrams but I'll give it a try...

Based on that example:

Animals/Vegetables/Minerals has-a (composition) tag

If I were to use that as a base with the Generic Foreign Key in
enclosure:

Animals (Zebra, Snake) has-a (composition) enclosure

But what I want to achieve is:

Enclosure has-a (composition) Animal (Zebra, Snake)


And that's kind of why I did the models that way.

I'm starting to think that Django may not be able to support this type
of design without multi-table inheritance which I don't feel is a
particularly clean way of implementing this.  I also don't know if
Django's binding of models to a relational database model will lend
itself to this very well. :)

I'll keep looking anyway.

Thanks for the help!

Shay

On Aug 21, 7:18 pm, Kip Parker <[EMAIL PROTECTED]> wrote:
> Though I'm not sure what MTI is (Google suggest "Massage Training
> Institute", but that can't be right), what you're trying to do seems
> well within Django's capabilities.
>
> Generic relations allow you to create foreign keys to any other
> object, so you'd have a Generic Foreign Key in your enclosure, then
> that could contain any kind of animal (or tree, car or building for
> that matter). Have another look 
> here:http://www.djangoproject.com/documentation/models/generic_relations/,
> it's so close to what you're doing that I think you can steal most of
> the code you need.
>
> Alll the best,
>
> Kip
>
> On Aug 21, 6:40 am, Shay <[EMAIL PROTECTED]> wrote:
>
> > Hi,
>
> > Thanks for the tip, I found Generic Relations and GenericForeignKey
> > shortly after I posted this and you confirmed I was looking in the
> > right place. :)
>
> > It seemed a better idea to make Animalabstractsince I don't want it
> > to be able to be instantiated on its own.  ZooEnclosure should only be
> > able to accept anything that is a type of Animal but not Animal itself
> > since it contains no valuable information in isolation of its
> > subclasses. Is there a way of preventing this without making the 
> > classabstract?
>
> > Also are there any scalability issues with using MTI for this type of
> > design (Particularly on large tables)?
>
> > With respect to implementing that design as a generic relation (sort
> > of based onhttp://www.djangoproject.com/documentation/contenttypes/
> > andhttp://www.webmonkey.com/tutorial/Build_a_Microblog_with_Django),
> > I'm still a little fuzzy on this, but would the implementation be
> > something to the effect of:
>
> > class Animal(models.Model):
> >     content_type = models.ForeignKey(ContentType)
> >     object_id = models.PositiveIntegerField()
> >     content_object = generic.GenericForeignKey('content_type',
> > 'object_id')
> >     ...
>
> >     class Meta:
> >        abstract= True
>
> > class Zebra(Animal):
> >     /* Inherits the content_type, object_id, content_object attributes
> > from Animal */
> >     ...
>
> > class Snake(Animal):
> >     ...
>
> > class ZooEnclosure(models.Model):
> >     enclosureName = models.CharField(max_length=50)
>
> > And then when ZooEnclosure is instantiated (form or otherwise),
> > there's either hook or some signal event which will trigger the
> > creation of the instance of Animal.
>
> > Am I on the right track or completely off?
>
> > Also since ZooEnclosure could contain any type of animal, I can't
> > recreate a reverse GenericRelation here for inhabitedBy. Creating a
> > GenericRelation to Animal would, I'm guessing, leave me with the same
> > problem as before because I set it asabstract(and the same other
> > problem of unflattened table hierarchy if I didn't set it asabstract).  Is 
> > it possible to specify this in the model?
>
> > If these are elementary questions, my apologies, I'm still trying to
> > get my head around how all of this hangs together. :)
>
> > Thanks,
> > Shay
>
> > On Aug 20, 5:21 pm, Kip Parker <[EMAIL PROTECTED]> wrote:
>
> > > Maybe have a look at generic 
> > > relations?http://www.djangoproject.com/documentation/models/generic_relations/
>
> > > You could also use multi-table inheritance rather thanabstract
> > > classes, then use the parent class Animal as the key in ZooEnclosure.
> > >Abstractclasses can't exist on their own, which I expect is why you
> > > got the NoneType errors.
>
> > > Kip.
>
> > > On Aug 20, 3:57 am, Shay <[EMAIL PROTECTED]> wrote:
>
> > > > Hi,
>
> > > > I'm rather new to Django, so please bear with me. :P
>
> > > > I've been trying to figure out how to implement the following in
> > > > models:
>
> > > > class: Animal (abstractclass)
> > > > ...
>
> > > > class: Zebra (extends Animal)
> > > > ...
>
> > > > class: Snake (extends Animal)
> > > > ...
>
> > > > class: ZooEnclosure
> > > > String enclosureName
> > > > Animal inhabitedBy
>
> > > > So:
> > > > - This is a very trivial example
> > > > - Zebra and Snake are subclasses of theabstractclass Animal
> > > > - ZooEnclosure is composed of some sort of Animal where I could
> > > > feasibly use a Zebra or a Snake
>
> > > > Creating a new ZooEnclosure for every animal is not an option because
> > > > there're quite a few and could quite possibly result in a hundred
> > > > different classes just to change the animal.
>
> > > > I've looked at the MTI and ABC type documentation (and Google) but I'm
> > > > still not clear on how best to implement this in Django Models.
>
> > > > Oh and when I have attempted to leave Animalabstract, it gives me
> > > > NoneType errors.
>
> > > > I'm not sure what the best way to tackle this problem is, any
> > > > suggestions?
>
>
--~--~---------~--~----~------------~-------~--~----~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to