Changes between Version 1 and Version 2 of Ticket #25705, comment 16
- Timestamp:
- Jul 15, 2024, 12:30:49 PM (8 weeks ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #25705, comment 16
v1 v2 20 20 I ''think'' that would qualify as a form of emulation or best-effort wouldn't it? What guarantees do we have that the quoting is appropriate for all datatypes that these backends support as parameters? Are we feeling confident, knowing that users will attempt to pipe `str(qs.query)` into `raw` and that `Query.__str__` always use `DEFAULT_DB_ALIAS` for compilation #25947 (even if the proper backend can often only be determined as execution time) that we are exposing the right tools to users and we can commit to them being safe for the years to come? 21 21 22 IMO the usage of `raw(str(qs.query))`, and the main motive for this ticket, is a symptom of a lack of documented way for safely building and executing the SQL and parameters from a `QuerySet` object which makes me believe the focus should be on documenting `queryset.qs.sql_with_params()` first instead ?22 IMO the usage of `raw(str(qs.query))`, and the main motive for this ticket, is a symptom of a lack of documented way for safely building and executing the SQL and parameters from a `QuerySet` object which makes me believe the focus should be on documenting `queryset.qs.sql_with_params()` first instead. 23 23 24 24 As for the printing and copy-pasting into a shell use case we've reached an agreement that the only way to see the query with the parameters binded correctly is after executing it. Knowing that, and the fact `Query.__str__` is still pretty legible even without the exact mogrifying that only leaves the copy-pasting into a shell use case. Should we make it easier to retrieve the exact SQL associated with a particular queryset instead? Something like `QuerySet.executed_query: str | None` that is only present on ''evaluated'' querysets.