On Thu, Jul 5, 2012 at 2:33 PM, Tomas Neme <lacrymol...@gmail.com> wrote:
> I wanted to chang the subject because I didn't want to spam someone's
> plead for help into a design discussion, but then I thought, how am I
> gonna make sure this is read by the right people? Also, context would
> be lost, so.. sorry about this
>
> But I don't see how what you say makes sense.
>
> I mean, all the way starting from this:
>
>> No, you /should/ not. You may do this, but you will end up with two
>> tables that /do not share the records/.
>> From the OP's post it's obvious these classes share the data. Think of
>
> oh, yeah, completely obvious, of course. It's plain that Foo and Bar
> are just MEANT to be just subtypes of Base, you can tell just from the
> names!
>
> Sorry, I don't mean to sound cocky, but you're making a hell of an
> assumption about what Foo and Bar and Base are, here, and *I* and
> making a completely different, but I think by no means less acceptable
> one: that he just wants to share his python code.
>
>> Base as a table 'fruit' and the other two as apples and oranges. In this
>> case it doesn't make sense to duplicate the fruit data in the apples and
>> oranges table.
>
> As I said before, the only thing this *really* depends on is in this
> question: do you need to be able to do something in the lines of:
> Fruit.objects.all()? And even more so: will you EVER do fruit =
> Fruit()? If not, there's no difference whatsoever, except you'd be
> littering the database namespace with a useless table.
>
> Very big apps, like, say django-blog-zinnia use abstract classes for
> the ease of extension and share of information for VERY concrete
> concepts like EntryBase, which defines all the fields the app uses in
> it's views, so a user can define their own Entry(EntryBase) class.
>
Abstract inheritance and MTI inheritance solve different problems. MTI
is particularly useful for querying sets of related classes on common
attributes, where as this is impossible to do with concrete classes
derived from an abstract class.
In the example, it is evident that the OP wants MTI, since he includes
the foreign key links in the class definition - there is no clearer
indicator than this!
IE, if he had given this as the definition:
class Foo(Base):
carpet = models.IntegerField()
then it could have been ambiguous as to what he was asking. Explicitly
including the parent link made it explicitly clear what he wanted.
Personally, I tend to use abstract class inheritance to give
behaviour, and MTI class inheritance to provide hierarchical class
structures. There is no inheritance holy war, they do different
things.
Cheers
Tom
--
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.
