Fixed #14733: no longer "validate" .raw() queries.

Turns out that a lot more than just SELECT can return data, and this list is
very hard to define up front in a cross-database manner. So let's just assume
that anyone using raw() is at least halfway competant and can deal with
the error messages if they don't use a data-returning query.

Thanks to Christophe Pettus for the patch.

git-svn-id: http://code.djangoproject.com/svn/django/trunk@15803 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
Jacob Kaplan-Moss 2011-03-14 19:49:53 +00:00
parent f1f10a9ce2
commit fd2f18008c
3 changed files with 10 additions and 13 deletions

View File

@ -31,7 +31,6 @@ class RawQuery(object):
""" """
def __init__(self, sql, using, params=None): def __init__(self, sql, using, params=None):
self.validate_sql(sql)
self.params = params or () self.params = params or ()
self.sql = sql self.sql = sql
self.using = using self.using = using
@ -62,11 +61,6 @@ class RawQuery(object):
return [converter(column_meta[0]) return [converter(column_meta[0])
for column_meta in self.cursor.description] for column_meta in self.cursor.description]
def validate_sql(self, sql):
if not sql.lower().strip().startswith('select'):
raise InvalidQuery('Raw queries are limited to SELECT queries. Use '
'connection.cursor directly for other types of queries.')
def __iter__(self): def __iter__(self):
# Always execute a new query for a new iterator. # Always execute a new query for a new iterator.
# This could be optimized with a cache at the expense of RAM. # This could be optimized with a cache at the expense of RAM.

View File

@ -42,6 +42,10 @@ You could then execute custom SQL like so::
John Smith John Smith
Jane Jones Jane Jones
Of course, this example isn't very exciting -- it's exactly the same as
running ``Person.objects.all()``. However, ``raw()`` has a bunch of other
options that make it very powerful.
.. admonition:: Model table names .. admonition:: Model table names
Where'd the name of the ``Person`` table come from in that example? Where'd the name of the ``Person`` table come from in that example?
@ -56,9 +60,12 @@ You could then execute custom SQL like so::
:attr:`~Options.db_table` option, which also lets you manually set the :attr:`~Options.db_table` option, which also lets you manually set the
database table name. database table name.
Of course, this example isn't very exciting -- it's exactly the same as .. warning::
running ``Person.objects.all()``. However, ``raw()`` has a bunch of other
options that make it very powerful. No checking is done on the SQL statement that is passed in to ``.raw()``.
Django expects that the statement will return a set of rows from the
database, but does nothing to enforce that. If the query does not
return rows, a (possibly cryptic) error will result.
Mapping query fields to model fields Mapping query fields to model fields
------------------------------------ ------------------------------------

View File

@ -169,10 +169,6 @@ class RawQueryTests(TestCase):
authors = Author.objects.all() authors = Author.objects.all()
self.assertSuccessfulRawQuery(Author, query, authors, expected_annotations) self.assertSuccessfulRawQuery(Author, query, authors, expected_annotations)
def testInvalidQuery(self):
query = "UPDATE raw_query_author SET first_name='thing' WHERE first_name='Joe'"
self.assertRaises(InvalidQuery, Author.objects.raw, query)
def testWhiteSpaceQuery(self): def testWhiteSpaceQuery(self):
query = " SELECT * FROM raw_query_author" query = " SELECT * FROM raw_query_author"
authors = Author.objects.all() authors = Author.objects.all()