On Monday 12 May 2014 12:27:01 Thomas Güttler wrote:
> Single Table Inheritance is used by ruby-on-rails and SQLAlchemy.
>
> Are there reasons why it is used in django?
>
Essentially, STI is a form of database denormalization. I think Django should
not encourage this.
> I would love to see a polymorphic inheritance solution in django.
>
Just to spell things out: You want to have models A, B(A), C(A) and D(B), so
that list(A.objects.all()) returns a list of objects of different types.
This sounds like a good idea in general, but there are devils in the
implementation details. In particular, I'd like to separate this issue from
the issue of STI -- polymorphism is an issue of processing the retrieved
records, and need not be tightly coupled to the database layout. The
polymorphism solution should work whether the records are fetched by the
equivalent of A.objects.all() or
A.objects.select_related(child_classes).all().
I think you can sort-of achieve STI by doing it the other way around: Define
all your hierarchy as abstract models, with one concrete model inheriting all
of them (I suspect any STI implementation in Django would have to do something
very similar "behind the scenes"). Pros and cons (as well as testing if this
actually works) are left as an exercise to the reader.
> I know that there are third party apps which provide this, but
> something like this should be in the core.
>
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.
> There was some discussion about this [1]. One reason against it was,
> that supporting not-null is not available. But a db constraint which
> checks the type and data column could solve this.
>
Django does not currently support arbitrary constraints well, so getting this
right (and cross-backend) might be somewhat of a challenge; which, in turn,
could justify including it in core. IMO, though, it would be much more useful
to support general constraints in core, and allow this to be done by users.
Either way, concrete suggestions welcome,
Shai.
> [1]
> https://code.djangoproject.com/wiki/ModelInheritance#a1.Modelingparentrela
> tionsinSQL
--
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/201405161246.01677.shai%40platonix.com.
For more options, visit https://groups.google.com/d/optout.
