Multi-table inheritance in Wagtail

[Lev Kanter]

In my understanding, Wagtail uses multi-table inheritance to provide the mechanism to implement different concrete "types" of pages. In working with the framework on a few projects so far, I've found this approach powerful, elegant and very easy to work with (mad props). On the other hand, the projects I've been playing around with Wagtail on are not particularly concerned about performance or operating at a large scale. It's a common mantra in the Django community to "avoid" multi-table/concrete inheritance "at all costs", most notably seen in recommendations from Jacob Kaplan-Moss and literature like Two Scoops of Django...the main line of reasoning being that basic queries which look straightforward become actually complex (and expensive) queries under the hood when multi-table inheritance is in play.

I'm curious to hear from the core Wagtail devs more about the thinking in this approach, if anyone in general has run into issues caused by multi-table inheritance in large-scale Wagtail sites, or if there are any specific related pitfalls to avoid.

Lev

[Tim Heap]

I have had a few issues with MTI, and I made some Github issues about them: #503, #560. It also does not play nicely with abstract models, or model mixins. I have found that the easiest way of mixing in extra functionality to your Page models is to make an abstract Model (not Page), and mix that in with a Page, otherwise you get strange clashes with MTI fields. Performance is another issue, and iterating over a Page queryset calling Page.specific on each one will use a huge number of database queries. PageQuerySet.specific (coming in 1.1) can help here, significantly reducing the number of database queries required, but traversing ForeignKeys to a Page will still need an unavoidable Page.specific call.

Wagtail does integrate with caching layers such as Varnish or Squid quite nicely from what I have heard, so if performance of plain Wagtail does become an issue, caching could save the day.

--
You received this message because you are subscribed to the Google Groups "Wagtail support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wagtail+u...@googlegroups.com.
To post to this group, send email to wag...@googlegroups.com.
Visit this group at http://groups.google.com/group/wagtail.
To view this discussion on the web, visit https://groups.google.com/d/msgid/wagtail/a3d27f50-91d7-4a52-8cf3-658f37e14df5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Matthew Westcott]

Hi Lev,
I wasn't aware of the strength of feeling against MTI when I made that design decision - I think the Django documentation at the time took the slightly milder line of "only use this if you really know what you're doing" - but I think it was (and is) the right decision. Logically it is a perfect fit for what Wagtail is doing - a set of models that are diverse in terms of the data they contain, but share certain traits (such as having a title and a position in the tree) that require them to be queried as a single unit. I was aware that by going with a lesser-used feature of Django, there was a risk of running into difficulties from it not being as well tested, documented or optimised - but my programmer's intuition was that those were all problems that could be fixed, whereas choosing a badly-fitting data model would leave us with problems that we'd be stuck with forever. To put it another way - if we hadn't used Django's multi-table inheritance, we would have had to reinvent our own version of it!

Cheers,
- Matt

[Lev Kanter]

Tim and Matt,

thanks for the notes and feedback, super helpful!