Dynamically return SQL statement maps for unit tests.

Review Request #11103 — Created July 30, 2020 and submitted

Information

Django Evolution
master

Reviewers

The SQL statement maps have traditionally been hard-coded dictionaries
of strings/lists of strings, accessible when importing the module. Over
time, these became a little more complex, handling variations in
statements based on the database version or Django version, but they
remained static dictionaries.

The problem with them being static is that it wasn't feasible to run the
unit tests againt different versions of MySQL, MariaDB, or Postgres
databases. The SQL was generated dynamically based on the capabilities
of a named database connection, like mysql_innodb, and that meant that
a new MySQL-based database couldn't be registered for testing an
alternate version.

To enable these more version-specific tests, all mappings are now
generated dynamically when needed. Instead of static dictionaries,
they're functions that take a database connection and return a mapping
dictionary. These functions can generate SQL suitable for that
connection without having to hard-code anything about the connection.

The resulting SQL maps are cached during the test run, so that they only
need to be generated once.

With this change, a test_db_settings.py is now free to define as many
databases as needed, and any of those can be passed to the test runner.
The template or this file has been updated with examples.

Unit tests pass on all versions of Django for all supported databases,
plus for additional database entries (tested with MariaDB, MySQL 5.6,
MySQL 5.7, and MySQL 8).

Summary ID
Dynamically return SQL statement maps for unit tests.
The SQL statement maps have traditionally been hard-coded dictionaries of strings/lists of strings, accessible when importing the module. Over time, these became a little more complex, handling variations in statements based on the database version or Django version, but they remained static dictionaries. The problem with them being static is that it wasn't feasible to run the unit tests againt different versions of MySQL, MariaDB, or Postgres databases. The SQL was generated dynamically based on the capabilities of a named database connection, like `mysql_innodb`, and that meant that a new MySQL-based database couldn't be registered for testing an alternate version. To enable these more version-specific tests, all mappings are now generated dynamically when needed. Instead of static dictionaries, they're functions that take a database connection and return a mapping dictionary. These functions can generate SQL suitable for that connection without having to hard-code anything about the connection. The resulting SQL maps are cached during the test run, so that they only need to be generated once. With this change, a `test_db_settings.py` is now free to define as many databases as needed, and any of those can be passed to the test runner. The template or this file has been updated with examples.
37cb1879b88070ded735cf0f17423660789e88b7
david
  1. Ship It!
  2. 
      
chipx86
Review request changed

Status: Closed (submitted)

Change Summary:

Pushed to master (cba6cf7)
Loading...