[Django] #29014: State that sqlite >= 3.7.15 is supported
Django
------------------------------------------+------------------------
Reporter: Дилян Палаузов | Owner: nobody
Type: Uncategorized | Status: new
Component: Documentation | Version: master
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
------------------------------------------+------------------------
django/docs/ref/databases.txt says:
Django supports PostgreSQL 9.4 and higher.
Django supports MySQL 5.6 and higher.
Django supports Oracle Database Server versions 12.1 and higher.
but it is silent about the required sqlite version.
commit 27193aea0088b238 drops support for sqlite < 3.7.15 and this should
be mentioned in releases/2.1.txt.
It is unfair to have at ref/databases.txt hyperlink to oracle.com, but not
to PostgreSQL.org, mysql.com and sqlite.org
--
Ticket URL: <https://code.djangoproject.com/ticket/29014>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: Дилян Палаузов | Owner: nobody
Cleanup/optimization |
Component: Documentation | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Tim Graham):
* type: Uncategorized => Cleanup/optimization
Old description:
> django/docs/ref/databases.txt says:
>
> Django supports PostgreSQL 9.4 and higher.
> Django supports MySQL 5.6 and higher.
> Django supports Oracle Database Server versions 12.1 and higher.
>
> but it is silent about the required sqlite version.
>
> commit 27193aea0088b238 drops support for sqlite < 3.7.15 and this should
> be mentioned in releases/2.1.txt.
>
> It is unfair to have at ref/databases.txt hyperlink to oracle.com, but
> not to PostgreSQL.org, mysql.com and sqlite.org
New description:
django/docs/ref/databases.txt says:
Django supports PostgreSQL 9.4 and higher.
Django supports MySQL 5.6 and higher.
Django supports Oracle Database Server versions 12.1 and higher.
but it is silent about the required sqlite version.
commit 27193aea0088b238e3ee0f0f235364a34a09265c drops support for sqlite <
3.7.15 and this should be mentioned in releases/2.1.txt.
It is unfair to have at ref/databases.txt hyperlink to oracle.com, but not
to PostgreSQL.org, mysql.com and sqlite.org
--
Comment:
As I asked in the comments of #28584, is it possible to install a version
of Python that has an older version of SQLite? I don't think that change
should affect anyone, but if it does, then we might consider reverting it.
--
Ticket URL: <https://code.djangoproject.com/ticket/29014#comment:1>
Django
Reporter: Дилян Палаузов | Owner: nobody
Cleanup/optimization |
Component: Documentation | Version: master
Severity: Normal | Resolution: needsinfo
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Tim Graham):
* status: new => closed
* resolution: => needsinfo
--
Ticket URL: <https://code.djangoproject.com/ticket/29014#comment:2>
Django
Reporter: Дилян Палаузов | Owner: nobody
Cleanup/optimization |
Component: Documentation | Version: master
Severity: Normal | Resolution: needsinfo
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Дилян Палаузов):
I have forgotten about #28584.
Running the tests with sqlite3 from
https://www.sqlite.org/src/tarball/sqlite.tar.gz?r=b078b588d617e078"
(version 3.6.23.1), without recompiling python after sqlite was installed,
prints:
{{{
Testing against Django installed in '/git/django/django' with up to 4
processes
Creating test database for alias 'default'...
Cloning test database for alias 'default'...
Cloning test database for alias 'default'...
Cloning test database for alias 'default'...
Cloning test database for alias 'default'...
Creating test database for alias 'other'...
Cloning test database for alias 'other'...
Cloning test database for alias 'other'...
Cloning test database for alias 'other'...
Cloning test database for alias 'other'...
System check identified no issues (14 silenced).
........................................................................................................EE............................................
test_action_column_class (admin_views.test_actions.AdminActionsTest)
failed:
TemplateDoesNotExist('admin/admin_views/subscriber/change_list.html,
admin/admin_views/change_list.html, admin/change_list.html',)
Unfortunately, the exception it raised cannot be pickled, making it
impossible
for the parallel test runner to handle it cleanly.
Here's the error encountered while trying to pickle the exception:
PicklingError("Can't pickle <function go_boom at 0x7f5ca1721378>: it's
not the same object as view_tests.templatetags.debugtags.go_boom",)
You should re-run this test with the --parallel=1 option to reproduce the
failure and get a correct traceback.
multiprocessing.pool.RemoteTraceback:
"""
Traceback (most recent call last):
File "/usr/local/lib/python3.5/multiprocessing/pool.py", line 119, in
worker
result = (True, func(*args, **kwds))
File "/git/django/django/test/runner.py", line 309, in _run_subsuite
result = runner.run(subsuite)
File "/git/django/django/test/runner.py", line 256, in run
test(result)
File "/usr/local/lib/python3.5/unittest/suite.py", line 84, in __call__
return self.run(*args, **kwds)
File "/usr/local/lib/python3.5/unittest/suite.py", line 122, in run
test(result)
File "/git/django/django/test/testcases.py", line 207, in __call__
super().__call__(result)
File "/usr/local/lib/python3.5/unittest/case.py", line 653, in __call__
return self.run(*args, **kwds)
File "/usr/local/lib/python3.5/unittest/case.py", line 613, in run
self._feedErrorsToResult(result, outcome.errors)
File "/usr/local/lib/python3.5/unittest/case.py", line 543, in
_feedErrorsToResult
result.addError(test, exc_info)
File "/git/django/django/test/runner.py", line 197, in addError
self.check_picklable(test, err)
File "/git/django/django/test/runner.py", line 130, in check_picklable
self._confirm_picklable(err)
File "/git/django/django/test/runner.py", line 104, in
_confirm_picklable
pickle.loads(pickle.dumps(obj))
_pickle.PicklingError: Can't pickle <function go_boom at 0x7f5ca1721378>:
it's not the same object as view_tests.templatetags.debugtags.go_boom
"""
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "./runtests.py", line 473, in <module>
options.exclude_tags,
File "./runtests.py", line 278, in django_tests
extra_tests=extra_tests,
File "/git/django/django/test/runner.py", line 600, in run_tests
result = self.run_suite(suite)
File "/git/django/django/test/runner.py", line 566, in run_suite
return runner.run(suite)
File "/usr/local/lib/python3.5/unittest/runner.py", line 176, in run
test(result)
File "/usr/local/lib/python3.5/unittest/suite.py", line 84, in __call__
return self.run(*args, **kwds)
File "/git/django/django/test/runner.py", line 372, in run
subsuite_index, events = test_results.next(timeout=0.1)
File "/usr/local/lib/python3.5/multiprocessing/pool.py", line 731, in
next
raise value
_pickle.PicklingError: Can't pickle <function go_boom at 0x7f5ca1721378>:
it's not the same object as view_tests.templatetags.debugtags.go_boom
}}}
Deleting libsqlite* from /usr/local/lib and using the old libsqlite from
/usr/lib makes the problem disappear.
Recompiling python 3.5 with the same sqlite version and running the tests
prints
{{{
Testing against Django installed in '/git/django/django' with up to 4
processes
Creating test database for alias 'default'...
Traceback (most recent call last):
File "/git/django/django/db/backends/base/base.py", line 216, in
ensure_connection
self.connect()
File "/git/django/django/db/backends/base/base.py", line 194, in connect
self.connection = self.get_new_connection(conn_params)
File "/git/django/django/db/backends/sqlite3/base.py", line 158, in
get_new_connection
conn = Database.connect(**conn_params)
sqlite3.NotSupportedError: URIs not supported
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "./runtests.py", line 473, in <module>
options.exclude_tags,
File "./runtests.py", line 278, in django_tests
extra_tests=extra_tests,
File "/git/django/django/test/runner.py", line 598, in run_tests
old_config = self.setup_databases()
File "/git/django/django/test/runner.py", line 545, in setup_databases
self.parallel, **kwargs
File "/git/django/django/test/utils.py", line 174, in setup_databases
serialize=connection.settings_dict.get('TEST', {}).get('SERIALIZE',
True),
File "/git/django/django/db/backends/base/creation.py", line 68, in
create_test_db
run_syncdb=True,
File "/git/django/django/core/management/__init__.py", line 141, in
call_command
return command.execute(*args, **defaults)
File "/git/django/django/core/management/base.py", line 335, in execute
output = self.handle(*args, **options)
File "/git/django/django/core/management/commands/migrate.py", line 79,
in handle
executor = MigrationExecutor(connection,
self.migration_progress_callback)
File "/git/django/django/db/migrations/executor.py", line 18, in
__init__
self.loader = MigrationLoader(self.connection)
File "/git/django/django/db/migrations/loader.py", line 49, in __init__
self.build_graph()
File "/git/django/django/db/migrations/loader.py", line 205, in
build_graph
self.applied_migrations = recorder.applied_migrations()
File "/git/django/django/db/migrations/recorder.py", line 61, in
applied_migrations
if self.has_table():
File "/git/django/django/db/migrations/recorder.py", line 44, in
has_table
return self.Migration._meta.db_table in
self.connection.introspection.table_names(self.connection.cursor())
File "/git/django/django/db/backends/base/base.py", line 255, in cursor
return self._cursor()
File "/git/django/django/db/backends/base/base.py", line 232, in _cursor
self.ensure_connection()
File "/git/django/django/db/backends/base/base.py", line 216, in
ensure_connection
self.connect()
File "/git/django/django/db/utils.py", line 89, in __exit__
raise dj_exc_value.with_traceback(traceback) from exc_value
File "/git/django/django/db/backends/base/base.py", line 216, in
ensure_connection
self.connect()
File "/git/django/django/db/backends/base/base.py", line 194, in connect
self.connection = self.get_new_connection(conn_params)
File "/git/django/django/db/backends/sqlite3/base.py", line 158, in
get_new_connection
conn = Database.connect(**conn_params)
django.db.utils.NotSupportedError: URIs not supported
}}}
All in all, as anybody can compile sqlite and python on their own, it has
to be documented which sqlite version Django requires. How sometimes
python is bundled is irrelevant.
--
Ticket URL: <https://code.djangoproject.com/ticket/29014#comment:3>
Django
Reporter: Дилян Палаузов | Owner: nobody
Cleanup/optimization |
Component: Documentation | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Дилян Палаузов):
* status: closed => new
* resolution: needsinfo =>
--
Ticket URL: <https://code.djangoproject.com/ticket/29014#comment:4>
Django
Reporter: Дилян Палаузов | Owner: nobody
Cleanup/optimization |
Component: Documentation | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Tim Graham):
My concern is that most everyone using SQLite will not be compiling it on
their own and if they are doing that, I'm not sure why they would use an
older version. Documenting a minimum SQLite version will mostly just
confuse users, I think. Do you have a use case for manually compiling an
older SQLite version or have a system where you found you needed to
upgrade SQLite?
--
Ticket URL: <https://code.djangoproject.com/ticket/29014#comment:5>
Django
Reporter: Дилян Палаузов | Owner: nobody
Cleanup/optimization |
Component: Documentation | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Дилян Палаузов):
Providing that people also don't compile manually Oracle, Postgresql or
Mysql, why are the required versions of those provided explicitly?
The use case of manually compiling an older SQLite is compiling manually a
current SQLite and not upgrading it. So at some time it gets very old.
--
Ticket URL: <https://code.djangoproject.com/ticket/29014#comment:6>
Django
Reporter: Дилян Палаузов | Owner: nobody
Cleanup/optimization |
Component: Documentation | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Tim Graham):
In my experience, I've never noticed the version of SQLite that I'm using.
For other databases, the version is much more prominent as there are often
major feature changes.
Django has existed for 12 years without documenting a minimum version of
SQLite and I haven't heard of any problems with that policy. If we see
someone have a problem as a result of
27193aea0088b238e3ee0f0f235364a34a09265c, then I'm happy to document a
minimum version or even revert this change. I don't want Django users to
have to manually install SQLite.
SQLite 3.7.14 (the newest unsupported version) was released in September
2012. I think most Unix users will be using an OS that's less than 6 years
old and on Windows, SQLite comes along with the Python installer so we
know the version there.
Have you actually manually compiled SQLite from older than 2012 and not
upgraded it or is this more of a theoretical concern?
--
Ticket URL: <https://code.djangoproject.com/ticket/29014#comment:7>
Django
Reporter: Дилян Палаузов | Owner: nobody
Cleanup/optimization |
Component: Documentation | Version: master
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Дилян Палаузов):
* status: new => closed
* resolution: => wontfix
Comment:
This is inconsistency and theoretical concern.
--
Ticket URL: <https://code.djangoproject.com/ticket/29014#comment:8>