Add support for Common Table Expression (CTE) queries

[Daniel Miller]

​django-cte-trees (also ​django-cte-forest) provides specialized uses of CTE queries for managing hierarchical data with recursive queries. To accomplish this, it uses the QuerySet.extra() API. This is my specific use case for CTE queries at the moment, however it leverages only one small part of what is possible with CTE queries: ​PostgreSQL, ​MySQL, ​SQL Server.

Another implementation supporting more general uses of CTE queries was ​presented on the developers mailing list, although I'm not sure it has ever made it any further than that. The code can be found ​on github. It appears to do its magic by mutating base_query.extra_tables, which seems to be a private/internal part of the ORM.

[Matthew Pava]

I have the same issue. I've been thinking about this and wondering if maybe we could just convert the Subquery object into a CTE (common table expression). They ought to work just the same, and it really shouldn't break backwards compatibility. At the same time, we could add a kwarg to the Subquery object, recursive, so that we can create a recursive CTE.

[ErikW]

I like Matthew's idea of reusing Subquery as the basis for CTEs since behind the scenes CTEs are really just syntactic sugar for Subqueries. I'd just like to add that being able to pull multiple values/aggregates from the Subquery/CTE would really push this over the top as a huge performance boost for complex analytical queries.

[Daniel Miller]

I implemented generic CTE support for Django: ​https://github.com/dimagi/django-cte

Would be happy to contribute this to be included with Django. Feedback is welcome.

[Aaron Lisman]

Replying to Daniel Miller:

I implemented generic CTE support for Django: ​https://github.com/dimagi/django-cte

Would be happy to contribute this to be included with Django. Feedback is welcome.

This has worked well for me, with the one exception of not being able to do an outer join since the library just uses extra_tables.

[Aaron Lisman]

I have a PR here, but it's incomplete in some ways: ​https://github.com/dimagi/django-cte/pull/1
I could use some help from someone more familiar with the Query object and how it handles joins/aliases.

[Daniel Miller]

It's now been refactored to not use extra_tables, and there is a secret (undocumented, experimental API) way to do a left outer join.

[Ole Laursen]

Daniel Miller: Can I humbly suggest you raise this on django-developers? I would guess this needs a discussion of the actual API for adding the table expressions and joining with them.

[Daniel Miller]

Ole Laursen: that's a good idea. Thank you for the suggestion. I'm a bit busy with other work right now, but I'll add it to my backlog.

[Javier Buzzi]

Bump.

[Javier Buzzi]

Any updates?

[Mariusz Felisiak]

Javier, patch is welcome. Leaving comments doesn't change anything and is not helpful.

[Simon Charette]

I wonder if this isn't a feature we can combine with the request for adding QuerySet.alias (#27719).

Adding an alias to a QuerySet expression would result in a CTE and could then be easily pruned if the queryset drops all references to this alias.