> If you ignore STI, I think it is quite straightforward to solve this with a parent model class which adds a type field, and manager methods to add the select_related calls and "interpret" the type field properly; so I don't see an immediate need for inclusion in core.
Well, you don't need select_related calls at all, if you're actually storing things in one table like "single-table inheritance" implies. I too was surprised to find Django doesn't do this, and was unable to find a good third-party app that does it. So I wrote my own: https://github.com/craigds/django-typed-models/ It works well and we have been using it in production for a couple years. It does rely on a few hacks that Django doesn't officially support, like proxy models with their own fields, which has unfortunately been broken in django 1.7 <https://code.djangoproject.com/ticket/22690>. I'd love to see better support for this in Django core. Regards Craig de Stigter On Thursday, 22 May 2014 21:02:48 UTC+12, Anssi Kääriäinen wrote: > > On 05/22/2014 11:13 AM, Shai Berger wrote: > >> Any thoughts on this idea? > >> > > Instinctively -- isn't it possible to achieve the same things today by > > overriding __new__ ? > My understanding is that achieving all the same things isn't possible. > The problem is that inside __new__ it is impossible to know if the call > to __new__ was made from database loading or from user code. It also > seems that it is impossible to alter the args and kwargs passed to > __init__(). In addition if one wants for some reason (speed, or not > invoking __setattr__) to assign values directly to the __dict__ of the > new class, then __new__() doesn't seem to offer any way to do that. > > It is true that STI is likely possible with usage of __new__() as long > as you don't want to change the arguments to the __init__ call of the > created object. > > As a side note I think direct assignment to __dict__ on model loading > would be a better design than the current __init__ call. For example > Django needs to do some pretty crazy stuff in __init__() to support > deferred field loading. With direct __dict__ assignment deferred model > creation is trivial. Also, loading from the database is a form of > deserialization, and when deserializing you want to load the model as it > were saved. The way to do this is to avoid __init__, __setattr__ and > descriptor __set__ calls. To avoid those the values should be assigned > directly to the __dict__ of the object. This is also used by Python's > deserialization. Of course, thinking about this is mostly academic. > Changing the way model loading from database is done has severe > backwards compatibility issues. Even django-core relies on descriptor > calls in some case. As an example to_python() method of custom fields is > called through a descriptor. > > - Anssi > -- 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/ffb11c40-c231-48d5-898a-71684536f55e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
