Thanks Malcolm! Extending a model you don't own was the use case I was missing. Thanks for clearing that up for me.
As I stated previously, I will be using explicit one to ones for the person can be a student, faculty, manager, etc. It looks like I could hammer mt inheritance to fit without too much trouble, but using it outside of it's intended area is just looking for trouble. If not now, then in the future. I was unaware of a behind the scenes select_related, I stand happily corrected! I will definitely use the type field and/or relation idea when I need to query a parent and treat the objects in an explicitly polymorphic way. The example I saw came up in irc, an individual had the need to query and date sort an archive of File model (the parent) and go through the list and treat articles, pictures, movies, audios etc. differently (the children). Wanting to fetch a qs based on parental info across all children, and then needing to treat different children differently, or have them act polymorphically, doesn't really seem like an edge case to me. But I can see that it would be a bear to implement in a generic way and might best be solved for a given applications needs. Ah, the intricacies of ORM. It makes my head hurt! Thanks again, Wayne On Apr 28, 1:15 am, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > On Sun, 2008-04-27 at 21:43 -0700, AmanKow wrote: > > Thanks for the reply, Malcolm. > > > Between what you wrote above and just creating the models and looking > > at the tables and indexes generated clarified the whole thing for > > me... > > > My purposes are similar to what I was attempting with the above > > example, with people instead of places (they can be any or all of > > faculty, students and managers). I thought that I could get some > > sugar from multitable inheritance, but I guess I will be using > > explicit OneToOneFields for this situation instead. > > > BTW, the db-api docs > > athttp://www.djangoproject.com/documentation/db-api/#one-to-one-relatio... > > still state that OneToOneField should not be used, as its semantics > > are in flux. Can I assume that is no longer a true statement? > > It's no longer true. I overlooked that it was also mentioned there. I > had remembered to update the model API documentation to remove the "in > flux" warning. I'll fix that at some point. > > > I guess the failed assumption I was under was that table inheritance > > would allow a single authoritative record for multiple children, and > > thus be much more space efficient than abstract inheritance with a > > separate copy of the parent for each child. Given that this is not > > the case, could I ask under which circumstances table inheritance is > > preferable to abstract inheritance? > > When you are wanting to extend existing data without modifying a > third-party table. After all, nothing says you can't just subclass a > model with one subclass (which is common in this case). Or when you are > frequently wanting to query the common data between a bunch of different > child models: with table inheritance, that requires querying the parent > table. With abstract inheritance, it requires querying every table for > all the affected models. > > > I can see that a situation where one has a need to query items from a > > single parent model, and process only parent information, would be > > very efficient. However, processing child information given a random > > parent is problematic with several subclasses, basically "downcasting" > > and catching exceptions until you hit the right class, (there was a > > discussion about the difficulties of this on irc the other day). > > As discussed on this list in the past, it's not possible to solve that > without modifying the parent model (to include a type code) or having an > external table to track the parent -> child relations for each parent > primary key value. You could implement the latter as a third party > product if you wanted to. We've decided in the past that it wasn't worth > including in core, since it's an extra piece of data that can easily get > out of sync -- particularly if your database is updated by other > processes. > > Also, it just isn't the major use case for database-based inheritance > models. If you are querying the parent table, it's because you care > about the *common* information. So that's right there at your > fingertips. > > If you frequently need to query the parent and descend to the children > and you control the parent, you can introduce a type code or use generic > relations (I'd personally use the former and am already doing so in a > few bits of code I've written). > > > Also, accessing parent information from children is less efficient. > > Huh? Since it's retrieved at construction (basically a default > select_related()) the only "inefficiency" is the code of one table join > and if you're noticing that difference you need to start using a proper > database. Table joins are fast at the database level, particularly in > the simplistic form we use. There are no extra queries made at the > database level when loading a multi-table model. > > > Anyhow, I was just wondering what the anticipated use case in for > > multitable inheritance is. > > Whatever is useful for you. We aim to provide possibilities, not > restrictions. However, people do seem to get caught up in the whole "gee > whiz" factor without thinking whether it suits there data needs. > > There is a very valid case for still using OneToOneFields in some data > modelling situations -- in particular, the case when there might be > multiple related objects (in different models) related to a single > parent. The one-to-one relation tells you that it's unique for that type > of model and adds no restriction to uniqueness of the parent amongst all > possible tables (which is why I said earlier model-inheritance is > totally enforced at the database level, because it's not possible). > > Model inheritance provides you with a Pythonic way to work with certain > data. But it's not the only way. As Ian Kelly has mentioned a couple of > times recently on django-developers, "has-a" or aggregation is often a > better type of composition for objects than "is-a" or inheritance. In > fact, there are some people who will argue until they expire from > exhaustion that since "is-a" is always implemented under the covers as > "has-a" for pretty much every language anyway, you should never design > for "is-a". I think those people are confused, since implementation can > be usefully separated from purpose, but it does highlight the fact that, > if you really want to, you can think about those sorts of things. > There's not always a single Right Answer, however. > > Regards, > Malcolm > > -- > Monday is an awful way to spend 1/7th of your > life.http://www.pointy-stick.com/blog/ --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
