Parameters are not adapted or quoted in Query.__str__

[Dmitry Dygalo]

Now it is just string interpolation of the SQL template with parameters and in most cases produces invalid queries for the following reasons:

• No quoting
• No adaptation. So, some python objects will be used as is, not like their SQL equivalents

Yes, there are situations, when output of Query.__str__ is equal to actual query. But for debugging reasons, it will be better to see real query here. Also it is logical and expected behavior of this method - to show actual query.

[Dmitry Dygalo]

Initial draft

[Dmitry Dygalo]

Commit: ​https://github.com/Stranger6667/django/commit/b2e36668a6877fe29923493e5669402dd30d6421
This issue is more general case of #24991

[Tim Graham]

This looks like a duplicate of #17741 and #25092 which are "wontfix", however, I'm not sure I see any harm in your proposal besides the question of whether or not it can be implemented on other database backends.

[Bernd Wechner]

Replying to Dmitry Dygalo:

Now it is just string interpolation of the SQL template with parameters and in most cases produces invalid queries for the following reasons:

• No quoting
• No adaptation. So, some python objects will be used as is, not like their SQL equivalents

Yes, there are situations, when output of Query.__str__ is equal to actual query. But for debugging reasons, it will be better to see real query here. Also it is logical and expected behavior of this method - to show actual query.

Fascinating. I inadvertantly filed a duplicate of this it seems:

https://code.djangoproject.com/ticket/30132#ticket

and I would dearly love this fixed. In essence Query.__str__ should return exactly what is logged as per here:

​https://docs.djangoproject.com/en/2.1/faq/models/#how-can-i-see-the-raw-sql-queries-django-is-running

so we can reliably see and extract teh SQL of a query in a production environment in which DEBUG is not enabled!

I would gladly fix this and PR it, if I had the skills and I am close to that, as I am coding and debugging python, but single stepping into Query.__str__ didn't find me a quick easy answer and I bailed for now. So if you have any tips as to where the code is that Query.__str__ uses to generate SQL and where the code is that logs SQL to connection.queries I canbegin to look at it consider how this might be fixed.

It seems to me an experience Django coder could fix this in minutes and that there should be a regression test for this kind of code:

qs=model.objects.somequeryset
sql=str(qs.query)
raw_qs=model.objects.raw(sql)

I have a test bed in which I confirmed this failure here:

​​https://github.com/bernd-wechner/DjangoTutorial/blob/238787c83ef8515aeeb405577980e71ff35664e8/Library/views.py

Let me know how I might help get this fixed sooner, given ti was reported 3 years ago and is still not fixed!

[GitHub <noreply@…>]

In 845042b3:

Refs #25705 -- Fixed invalid SQL generated by SQLFuncMixin.as_sql() in custom_lookups tests.

Generated SQL was invalid because parameters are quoted by a driver.

[Mariusz Felisiak]

IMO we should close all related tickets as duplicates:

• #24803 was marked as a duplicate (empty strings in parameters),
• #24991 was marked as a duplicate (range types in parameters).