From f91b5a7e4b2ac436b1fe3065b23217543d0f54c1 Mon Sep 17 00:00:00 2001 From: Aymeric Augustin Date: Sat, 9 Jan 2016 21:30:19 +0100 Subject: Fixed #26063 -- Crash when passing > 2000 params. If SQLITE_MAX_VARIABLE_NUMBER (default = 999) is changed at compile time to be greater than SQLITE_MAX_COLUMN (default = 2000), which Debian does by setting the former to 250000, Django raised an exception on queries containing more than 2000 parameters when DEBUG = True. --- tests/backends/tests.py | 12 ++++++++++++ 1 file changed, 12 insertions(+) (limited to 'tests/backends') diff --git a/tests/backends/tests.py b/tests/backends/tests.py index 693bb77180..460b522079 100644 --- a/tests/backends/tests.py +++ b/tests/backends/tests.py @@ -426,6 +426,18 @@ class LastExecutedQueryTest(TestCase): substituted = "SELECT '\"''\\'" self.assertEqual(connection.queries[-1]['sql'], substituted) + @unittest.skipUnless(connection.vendor == 'sqlite', + "This test is specific to SQLite.") + def test_large_number_of_parameters_on_sqlite(self): + # If SQLITE_MAX_VARIABLE_NUMBER (default = 999) has been changed to be + # greater than SQLITE_MAX_COLUMN (default = 2000), last_executed_query + # can hit the SQLITE_MAX_COLUMN limit. See #26063. + cursor = connection.cursor() + sql = "SELECT MAX(%s)" % ", ".join(["%s"] * 2001) + params = list(range(2001)) + # This should not raise an exception. + cursor.db.ops.last_executed_query(cursor.cursor, sql, params) + class ParameterHandlingTest(TestCase): -- cgit v1.3