| 9 | | === Test suite failures === |
| 10 | | |
| 11 | | As of r8889 (1.0rc1), the test suite is showing the following failure(s) when run under Windows (XP 32 bits) + official Python 2.5.2: |
| 12 | | |
| 13 | | * Ticket #7570 when using the sqlite3 Django DB backend (official Python 2.5.2 Windows distribution includes SQLite 3.3.4). |
| 14 | | |
| 15 | | ==== ticket #7570 ==== |
| 16 | | |
| 17 | | This test (and other two similar tests) fails: |
| 18 | | |
| 19 | | {{{ |
| 20 | | #!python |
| 21 | | Bug #7087 -- dates with extra select columns |
| 22 | | >>> Item.objects.dates('created', 'day').extra(select={'a': 1}) |
| 23 | | [datetime.datetime(2007, 12, 19, 0, 0), datetime.datetime(2007, 12, 20, 0, 0)] |
| 24 | | }}} |
| 25 | | |
| 26 | | Error is: |
| 27 | | |
| 28 | | {{{ |
| 29 | | ====================================================================== |
| 30 | | FAIL: Doctest: regressiontests.queries.models.__test__.API_TESTS |
| 31 | | ---------------------------------------------------------------------- |
| 32 | | Traceback (most recent call last): |
| 33 | | File "C:\ramiro\django-trunk\django\test\_doctest.py", line 2180, in runTest |
| 34 | | raise self.failureException(self.format_failure(new.getvalue())) |
| 35 | | AssertionError: Failed doctest test for regressiontests.queries.models.__test__.API_TESTS |
| 36 | | File "C:\ramiro\django-trunk\tests\regressiontests\queries\models.py", line unknown line number, in API_TESTS |
| 37 | | |
| 38 | | ---------------------------------------------------------------------- |
| 39 | | File "C:\ramiro\django-trunk\tests\regressiontests\queries\models.py", line ?, in regressiontests.queries.models.__test__.API_TESTS |
| 40 | | Failed example: |
| 41 | | Item.objects.dates('created', 'day').extra(select={'a': 1}) |
| 42 | | Exception raised: |
| 43 | | Traceback (most recent call last): |
| 44 | | File "C:\ramiro\django-trunk\django\test\_doctest.py", line 1267, in __run |
| 45 | | compileflags, 1) in test.globs |
| 46 | | File "<doctest regressiontests.queries.models.__test__.API_TESTS[169]>", line 1, in <module> |
| 47 | | Item.objects.dates('created', 'day').extra(select={'a': 1}) |
| 48 | | File "c:\ramiro\django-trunk\django\db\models\query.py", line 129, in __repr__ |
| 49 | | return repr(list(self)) |
| 50 | | File "c:\ramiro\django-trunk\django\db\models\query.py", line 141, in __len__ |
| 51 | | self._result_cache.extend(list(self._iter)) |
| 52 | | File "c:\ramiro\django-trunk\django\db\models\sql\subqueries.py", line 351, in results_iter |
| 53 | | for rows in self.execute_sql(MULTI): |
| 54 | | File "c:\ramiro\django-trunk\django\db\models\sql\query.py", line 1607, in execute_sql |
| 55 | | cursor.execute(sql, params) |
| 56 | | File "c:\ramiro\django-trunk\django\db\backends\sqlite3\base.py", line 136, in execute |
| 57 | | return Database.Cursor.execute(self, query, params) |
| 58 | | OperationalError: ORDER BY terms must not be non-integer constants |
| 59 | | |
| 60 | | |
| 61 | | ---------------------------------------------------------------------- |
| 62 | | Ran 253 tests in 433.032s |
| 63 | | |
| 64 | | FAILED (failures=1) |
| 65 | | }}} |
| 66 | | |
| 67 | | A minimal models.py file that shows the problem (extracted from the above regression test): |
| 68 | | |
| 69 | | {{{ |
| 70 | | #!python |
| 71 | | """ |
| 72 | | >>> time1 = datetime.datetime(2007, 12, 19, 22, 25, 0) |
| 73 | | >>> time2 = datetime.datetime(2007, 12, 19, 21, 0, 0) |
| 74 | | >>> time3 = datetime.datetime(2007, 12, 20, 22, 25, 0) |
| 75 | | >>> time4 = datetime.datetime(2007, 12, 20, 21, 0, 0) |
| 76 | | >>> i1 = Item(name='one', created=time1, modified=time1) |
| 77 | | >>> i1.save() |
| 78 | | >>> i2 = Item(name='two', created=time2) |
| 79 | | >>> i2.save() |
| 80 | | >>> i3 = Item(name='three', created=time3) |
| 81 | | >>> i3.save() |
| 82 | | >>> i4 = Item(name='four', created=time4) |
| 83 | | >>> i4.save() |
| 84 | | |
| 85 | | >>> Item.objects.dates('created', 'day').extra(select={'a': 1}) |
| 86 | | [datetime.datetime(2007, 12, 19, 0, 0), datetime.datetime(2007, 12, 20, 0, 0)] |
| 87 | | |
| 88 | | """ |
| 89 | | |
| 90 | | from django.db import models |
| 91 | | import datetime |
| 92 | | |
| 93 | | class Item(models.Model): |
| 94 | | name = models.CharField(max_length=10) |
| 95 | | created = models.DateTimeField() |
| 96 | | modified = models.DateTimeField(blank=True, null=True) |
| 97 | | |
| 98 | | class Meta: |
| 99 | | ordering = ['name'] |
| 100 | | |
| 101 | | def __unicode__(self): |
| 102 | | |
| 103 | | return self.name |
| 104 | | }}} |
| 105 | | |
| 106 | | The SQL being generated by Django is correct: |
| 107 | | |
| 108 | | {{{ |
| 109 | | #!python |
| 110 | | >>> Item.objects.dates('created', 'day').extra(select={'a': 1}).query.as_sql() |
| 111 | | ('SELECT DISTINCT (1) AS "a", django_date_trunc("day", "sqlite3_dates_item"."created") FROM "sqlite3_dates_item" ORDER BY 1 ASC', ()) |
| 112 | | }}} |
| 113 | | |
| 114 | | Problem seems to be related to some bug in the version of pysqlite2 or sqlite3 (main suspect) included with the official Python 2.5.2 win32 installer (2.3.2 and 3.3.4 respectively): |
| 115 | | |
| 116 | | {{{ |
| 117 | | #!python |
| 118 | | Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit (Intel)] on win32 |
| 119 | | Type "help", "copyright", "credits" or "license" for more information. |
| 120 | | >>> from sqlite3 import dbapi2 |
| 121 | | >>> print dbapi2.version_info |
| 122 | | (2, 3, 2) |
| 123 | | >>> print dbapi2.sqlite_version_info |
| 124 | | (3, 3, 4) |
| 125 | | }}} |
| 126 | | |
| 127 | | The win32 installer for Python 2.5 ships the same combination of pysqlite/sqlite versions and exhibits the same problem. The tests were also run under some other Windows- and Linux-based scenarios. |
| 128 | | |
| 129 | | Summarizing: |
| 130 | | |
| 131 | | || '''Platform''' || '''Python version''' || '''pysqlite2 version''' || '''sqlite version''' || '''works?''' || '''Notes''' || |
| 132 | | || win32 || 2.4.4 || 2.3.0 (external) || 3.3.6 || YES || || |
| 133 | | || Debian Linux || 2.4.4 || 2.3.2 (external) || 3.3.8 || YES || || |
| 134 | | || win32 || 2.5 || 2.3.2 (built-in sqlite3)|| 3.3.4 || NO || || |
| 135 | | || Debian Linux || 2.5 || 2.3.2 (built-in sqlite3)|| 3.3.8 || YES || || |
| 136 | | || win32 || 2.5.2 || 2.3.2 (built-in sqlite3)|| 3.3.4 || NO || || |
| 137 | | || win32 || 2.5.2 || 2.4.1 (external) || 3.5.2 || YES || '''*''' || |
| 138 | | || Debian Linux || 2.5.2 || 2.3.2 (built-in sqlite3)|| 3.5.9 || YES || || |
| 139 | | || custom Linux || 2.5.2 || ? || 3.2.7 || NO || || |
| 140 | | |
| 141 | | Note that the tests also fail under Linux with early sqlite versions. |
| 142 | | |
| 143 | | ===== Possible solution ===== |
| 144 | | |
| 145 | | As the table above shows, version <= 3.3.4 of sqlite seems to be affected by this bug whilst version >=3.3.6 isn't. |
| 146 | | |
| 147 | | We think it's a SQLite bug reported in [http://www.sqlite.org/cvstrac/tktview?tn=1768 this] ticket and fixed in [http://www.sqlite.org/cvstrac/chngview?cn=3173 this] commit six days after 3.3.5 was tagged, so it would be safe to assume that 3.3.5 is also affected. This is the complete changelog between 3.3.4 and 3.3.6: http://www.sqlite.org/cvstrac/timeline?d=115&e=2006-Jun-06&c=2&px=&s=9&dm=1&x=1 |
| 148 | | |
| 149 | | As sqlite/pysqlite development continues, the pysqlite project keeps publishing new win32 binary installers for Python 2.5. Latest as of June 29, 2008 is version 2.4.1 ({{{pysqlite-2.4.1.win32-py2.5.exe}}}) that uses sqlite version 3.5.2 (see entry marked with '''*''' in the table above.) |
| 150 | | |
| 151 | | ===== How does this affect Django ===== |
| 152 | | |
| 153 | | The problem doesn't lie within Django itself, but one or both of the following proposals would help users solve this problem: |
| 154 | | |
| 155 | | * Document the fact that SQLite 3.3.6 is needed. As of now Windows users using stable, supported, non-beta versions of python need to be directed to also manually apply the patch below to their copies of Django. |
| 156 | | * Invert the order being in which the sqlite3 backend tries loading the sqlite DB-API2 modules ({{{django/db/backends/sqlite3/base.py}}}) to try loading pysqlite2 first and if this fails then try loading sqlite3. Reasoning behind this is that this would allow the user to take advantage of newer pysqlite2/sqlite3 versions he/she may have installed even if using Python 2.5.x. This might be true and desirable regardless of platform: |
| 157 | | |
| 158 | | {{{ |
| 159 | | #!diff |
| 160 | | --- base.py 2008-04-27 00:58:35.000000000 -0300 |
| 161 | | +++ base.py-proposed 2008-06-29 20:48:29.000000000 -0300 |
| 162 | | @@ -3,15 +3,16 @@ |
| 163 | | |
| 164 | | Python 2.3 and 2.4 require pysqlite2 (http://pysqlite.org/). |
| 165 | | |
| 166 | | -Python 2.5 and later use the sqlite3 module in the standard library. |
| 167 | | +Python 2.5 and later use pysqlite2 or the sqlite3 module in the standard |
| 168 | | +library. |
| 169 | | """ |
| 170 | | |
| 171 | | from django.db.backends import BaseDatabaseWrapper, BaseDatabaseFeatures, BaseDatabaseOperations, util |
| 172 | | try: |
| 173 | | try: |
| 174 | | - from sqlite3 import dbapi2 as Database |
| 175 | | - except ImportError: |
| 176 | | from pysqlite2 import dbapi2 as Database |
| 177 | | + except ImportError: |
| 178 | | + from sqlite3 import dbapi2 as Database |
| 179 | | except ImportError, e: |
| 180 | | import sys |
| 181 | | from django.core.exceptions import ImproperlyConfigured |
| 182 | | }}} |
| | 9 | * DjangoOnWindows/TestSuiteFailures |