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.
--
"The whole of Japan is pure invention. There is no such country, there
are no such people" --Oscar Wilde
|_|0|_|
|_|_|0|
|0|0|0|
(\__/)
(='.'=)This is Bunny. Copy and paste bunny
(")_(") to help him gain world domination.
--
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.
