mirror of
https://github.com/django/django.git
synced 2025-10-24 06:06:09 +00:00
Support 'pyformat' style parameters in raw queries, Refs #10070
Add support for Oracle, fix an issue with the repr of RawQuerySet, add tests and documentations. Also added a 'supports_paramstyle_pyformat' database feature, True by default, False for SQLite. Thanks Donald Stufft for review of documentation.
This commit is contained in:
@@ -623,6 +623,14 @@ If you're getting this error, you can solve it by:
|
||||
SQLite does not support the ``SELECT ... FOR UPDATE`` syntax. Calling it will
|
||||
have no effect.
|
||||
|
||||
"pyformat" parameter style in raw queries not supported
|
||||
-------------------------------------------------------
|
||||
|
||||
For most backends, raw queries (``Manager.raw()`` or ``cursor.execute()``)
|
||||
can use the "pyformat" parameter style, where placeholders in the query
|
||||
are given as ``'%(name)s'`` and the parameters are passed as a dictionary
|
||||
rather than a list. SQLite does not support this.
|
||||
|
||||
.. _sqlite-connection-queries:
|
||||
|
||||
Parameters not quoted in ``connection.queries``
|
||||
|
||||
@@ -337,6 +337,12 @@ Minor features
|
||||
default) to allow customizing the :attr:`~django.forms.Form.prefix` of the
|
||||
form.
|
||||
|
||||
* Raw queries (``Manager.raw()`` or ``cursor.execute()``) can now use the
|
||||
"pyformat" parameter style, where placeholders in the query are given as
|
||||
``'%(name)s'`` and the parameters are passed as a dictionary rather than
|
||||
a list (except on SQLite). This has long been possible (but not officially
|
||||
supported) on MySQL and PostgreSQL, and is now also available on Oracle.
|
||||
|
||||
Backwards incompatible changes in 1.6
|
||||
=====================================
|
||||
|
||||
|
||||
@@ -166,9 +166,17 @@ argument to ``raw()``::
|
||||
>>> lname = 'Doe'
|
||||
>>> Person.objects.raw('SELECT * FROM myapp_person WHERE last_name = %s', [lname])
|
||||
|
||||
``params`` is a list of parameters. You'll use ``%s`` placeholders in the
|
||||
query string (regardless of your database engine); they'll be replaced with
|
||||
parameters from the ``params`` list.
|
||||
``params`` is a list or dictionary of parameters. You'll use ``%s``
|
||||
placeholders in the query string for a list, or ``%(key)s``
|
||||
placeholders for a dictionary (where ``key`` is replaced by a
|
||||
dictionary key, of course), regardless of your database engine. Such
|
||||
placeholders will be replaced with parameters from the ``params``
|
||||
argument.
|
||||
|
||||
.. note:: Dictionary params not supported with SQLite
|
||||
|
||||
Dictionary params are not supported with the SQLite backend; with
|
||||
this backend, you must pass parameters as a list.
|
||||
|
||||
.. warning::
|
||||
|
||||
@@ -181,14 +189,21 @@ parameters from the ``params`` list.
|
||||
|
||||
**Don't.**
|
||||
|
||||
Using the ``params`` list completely protects you from `SQL injection
|
||||
Using the ``params`` argument completely protects you from `SQL injection
|
||||
attacks`__, a common exploit where attackers inject arbitrary SQL into
|
||||
your database. If you use string interpolation, sooner or later you'll
|
||||
fall victim to SQL injection. As long as you remember to always use the
|
||||
``params`` list you'll be protected.
|
||||
``params`` argument you'll be protected.
|
||||
|
||||
__ http://en.wikipedia.org/wiki/SQL_injection
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
In Django 1.5 and earlier, you could pass parameters as dictionaries
|
||||
when using PostgreSQL or MySQL, although this wasn't documented. Now
|
||||
you can also do this whem using Oracle, and it is officially supported.
|
||||
|
||||
|
||||
.. _executing-custom-sql:
|
||||
|
||||
Executing custom SQL directly
|
||||
|
||||
Reference in New Issue
Block a user