On Fri, 2006-06-09 at 13:25 +0200, Gábor Farkas wrote: > Malcolm Tredinnick wrote: > > On Wed, 2006-06-07 at 11:34 +0100, David Reynolds wrote: > >> Hi, > >> > >> I seem to remember reading either on the mailing list or IRC channel > >> that sub-classing doesn't work at the moment, is that correct? It > >> seems to work to some extent but I can't recreate the behaviour that > >> replaces_model='modelname' used to do. Is this going to be readded, > >> or a better way of doing it added and what sort of timescales are on > >> this? > > > > So nobody's pointed out that this was discussed here within the last > > couple of weeks. The latest status is this: > > http://groups.google.com/group/django-users/browse_frm/thread/827c7ba291a319e0/c9038b1e540deec4#c9038b1e540deec4 > > > > It's not part of Summer of Code or anything, but it is being worked on. > > > > hi Malcolm, > > great to hear that things are progressing also there... > > if i may ask... are you doing it with table-joins?
Yes. > > if yes... won't be there a performance penalty every time i want to > access a field defined in the parent model? "You can't make an omlette without breaking some eggs". It's not enough to worry about and the advantages outweigh the disadvantages. Some of these are discussed on the wiki page. To those I would also add (a) the danger of changing third-party tables just because you are inheriting from their model; and (b) multiple inheritance (particularly mix-ins) become very hard to administer in the denormalised table version (you end up with the same model spread across multiple tables). Also, counter-intuitively, it is sometimes faster to join a couple of tables rather than reading from a very wide non-normalised table. This is because you cannot read only part of a row from disk. Even to get three columns, you need to read in all 140 or whatever you have of them from the table. This should be rare in the Django ORM world (it would only kick in for a very bushy -- large branching factor -- inheritance hierarchy), but it's interesting to keep in the back of your mind in any case. Finally, it is premature optimisation to worry about this. Databases are *designed* to have things in multiple tables. Having huge flat tables is only an optimisation and design compromise that one should want to make after carefully eliminating every other option as acceptable. It's why spreadsheets don't make good databases. It's why you learn about normal forms in data design courses at universities. I am choosing to do things in the most natural (to me) fashion initially and trust the database to do its bit and only then, if it turns out to be unacceptable, should somebody look at where trade-offs can be made. When the code arrives, people can time it all they like. I have some timing tests I am doing as I go along. They are not discouraging. Regards, Malcolm --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
