Support adding an SQL comment in queries

[Adam Johnson]

This feature gives QuerySet a .comment(text) method that inserts text into a comment in the output SQL query, right after the SELECT [DISTINCT] part. This has two uses:

1. For all database backends, this can be used for feature-to-query tracking. For example, you might override def queryset on your admin classes to use comment() to insert the name of the admin class generating the query, making query analysis (processlist, slow query logs, etc.) easier to track back to the point in the code generating the queries. This is not trivial.

I've seen Facebook have nice tools that automatically insert file/line number summaries into queries as comments to make analysis easy. Adding comment() would making this easy for custom QuerySet subclasses to do this however they want, with e.g. caller inspection at __init__ time.

2. For the MySQL and Oracle backends, flags and optimizer hints can be added. Both have a number of options for queries that are otherwise unsupported on django, and they can be inserted with special comments.

This is my current motivation - I had a pretty complex 3-join/5-subquery MySQL query today that could only be made good on the ORM by adding MySQL's "STRAIGHT_JOIN" hint, and the only way I found to do this in Django at current was to monkey-patch the MySQL backend CursorWrapper's execute() to rewrite the generated query with regexes... :( And it couldn't use raw() since it was being passed to the admin with the ability to filter it.

I couldn't find any historical tickets on optimizer hints.

[Adam Johnson]

Ticket ​https://github.com/django/django/pull/4495

No documentation yet, don't know if it will be accepted...

[Adam Johnson]

For reference (checking I did get the right place for Oracle and MySQL query hints):

1. MySQL hints are listed in its syntax ​https://dev.mysql.com/doc/refman/5.5/en/select.html (STRAIGHT_JOIN, SQL_NO_CACHE, etc.). They can be inserted as comments by starting the comment with an exclamation mark, which pretty much means "this is not a comment" (the reason this exists is that if you follow the exclamation mark with an encoded version number, that SQL will only be executed on versions of the server at that version or above). Also newer more powerful hints are coming in 5.7 with comments that start with a + : ​https://dev.mysql.com/worklog/task/?id=8017

2. Oracle has extensive documentation on its hints which appear only in conditional comments, although the page is lacking in examples: ​http://docs.oracle.com/cd/B19306_01/server.102/b14211/hintsref.htm . However the syntax for SELECT does show hints going *before* DISTINCT: ​http://docs.oracle.com/cd/B28359_01/server.111/b28286/statements_10002.htm , however this blog post shows them after: ​http://www.dba-oracle.com/t_index_fast_full_scan.htm .

[Anssi Kääriäinen]

It might be a bit ugly if we have to support multiple places for the comment. What about MSSQL, DB2 and other non-core backends? I'm not sure what is the best way to alter the generated SQL if we need support for injecting hints in arbitrary places.

Also, are we ok with support for read queries only, or should we have it for update/delete/insert queries, too? The delete queries might be especially hard for cascades. Maybe we should aim for "user generated select queries only" for the first implementation?

[Adam Johnson]

MSSQL - it appears all hints come in an OPTION clause after HAVING: ​https://msdn.microsoft.com/en-us/library/ms189499.aspx
DB2 - it appears hints come in a %_HINTS clause after WHERE: ​http://scn.sap.com/thread/1573275

So yes, unfortunately this is not general-purpose enough for adding query hints.

I did try an implementation with the comments injected on DeleteSQLCompiler but the cascade did lead to it pretty broken since the query hint for delete was carried to the selects. User generated selects only sounds good - the current patch does update too, but it's not often you want to add hints on them anyway as there are no joins.

[Adam Johnson]

For the record, here's the first open-source version of the regex-based SQL-rewriting code I have that adds MySQL's STRAIGHT_JOIN: ​https://github.com/adamchainz/django-mysql/commit/cf69c24962c4a22cc2fac5b29319777ee2a44fb0 . If we can't add .comment(), this is the probably the best solution possible.

[Hannes Ljungberg]

PR: ​https://github.com/django/django/pull/15711

[Michael Warkentin]

I've recently come across ​https://github.com/ossc-db/pg_hint_plan which also provides support for plan hints in Postgres (which I'd like to use, and the reason I've found this issue). Just thought that would be worth considering as well during implementation if this work goes through.