Late reply I know but I see a lot of FUD in this thread and I want to try and clear it up.
> in the general case, STI means you have to make almost all the fields in your model NULLable. You lose any semblance of having an actual database schema, and end up writing a whole lot of code to re-implement the features of a database schema instead of using the well tested, robust implementation that the database provides. This is just not true. Well implemented STI does *not* turn your database table into a key-value store. You can use the fields of the table just like you would normally use them. The *only* abnormal consideration here is that, if you *need* for some reason to have a field defined on a child class instead of all fields defined on the base model, then such fields must be nullable. In my experience users of django-typed-models will have 90-100% of their fields defined on the base class for each abstract type, meaning that only 0-10% of the fields will have to be nullable. There is no deviation from normal use of the ORM, and no hoops to jump through to ensure db consistency. In my own case, I am using django-typed-models with all the fields on the base class. In fact, django-typed-models didn't initially allow for fields on child models at all, and I still don't use that behaviour. I did merge a PR to add the possibility for fields defined on child models, and I can see how that would be useful. If you use that functionality you just have to be okay with those fields being nullable. > Django was designed around PostgreSQL, a database that cares about its data. And I wouldn't use MySQL if you paid me. But this is a straw man; if you're using STI you *might* be using fields that are nullable but could otherwise be non-nullable, but this shouldn't imply that you don't care about your data. I reserve judgment on whether STI should be included in core. It works fine in a third-party app. Some better support for it in core would be helpful, since currently I'm relying on some unsupported stuff that the core devs could decide to break at any time. But it's a better solution to certain problems than MTI is, and it doesn't deserve the bashing that some people seem to give it. Use the right tool for the job. If that's STI then use STI :) Craig de Stigter On Saturday, 7 June 2014 06:05:29 UTC+12, Aymeric Augustin wrote: > > On 6 juin 2014, at 09:42, Thomas Güttler <h...@tbz-pariv.de <javascript:>> > wrote: > > > I think it is a "not invented here" syndrome: Ruby on Rails did it > before. That's > > a reason to do it different. > > The reason is more simple. > > Rails was designed around MySQL, a database with a rather casual > relationship > to data integrity. It will happily truncate data or save invalid values in > the name of > performance. In the same spirit STI trades data integrity for speed. It > avoids joins, > which can be very slow on MySQL, but also prevents the database from > enforcing > constraints. > > Django was designed around PostgreSQL, a database that cares about its > data. > > That explains many differences in the design of the Rails and Django ORMs. > > -- > Aymeric. > > > > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/d5114d13-a1d2-4f28-85c6-1771d3896f2e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
