State that sqlite >= 3.7.15 is supported

[Дилян Палаузов]

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

[Tim Graham]

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.

[Дилян Палаузов]

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.

[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?

[Дилян Палаузов]

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.

[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?

[Дилян Палаузов]

This is inconsistency and theoretical concern.