On 5-7-2012 15:33, Tomas Neme wrote: > 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!
Not really. But from the question: "But how can I tell south to fill the super class with the data from the old schema?" I found it quite obvious. On second thought, it's possible he can decouple the data. > 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. And you're spreading records over two different tables and making it impossible to enforce uniqueness on shared attributes. So it's not just about creating an instance. > 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. Good point. -- Melvyn Sopacua -- 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.
