The sql_flush() positional argument sequences is replaced by the boolean
keyword-only argument reset_sequences. This ensures that the old
function signature can't be used by mistake when upgrading Django. When
the new argument is True, the sequences of the truncated tables will
reset. Using a single boolean value, rather than a list, allows making a
binary yes/no choice as to whether to reset all sequences rather than a
working on a completely different set.
This caused misplacing parameters in logged SQL queries.
Regression in 79065b55a70cd220820a260a1c54851b7be0615a.
Thanks Hans Aarne Liblik for the report.
- Used selected "databases" instead of django.db.connections.
- Made routers in tests.migrations skip migrations on unexpected
databases.
- Added DiscoverRunnerGetDatabasesTests.assertSkippedDatabases() hook
which properly asserts messages about skipped databases.
Made DatabaseWrapper thread sharing logic reentrant. Used a reference
counting like scheme to allow nested uses.
The error appeared after 8c775391b78b2a4a2b57c5e89ed4888f36aada4b.
Removed DatabaseIntrospection.table_name_converter()/column_name_converter()
and use instead DatabaseIntrospection.identifier_converter().
Removed DatabaseFeatures.uppercases_column_names.
Thanks Tim Graham for the initial patch and review and Simon Charette
for the review.
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.
This new technique is more straightforward and compatible with test
parallelization, where the effective database connection settings no
longer match settings.DATABASES.
Found cases where testing code was doing
try:
whatever
except (some excption type):
self.fail("exception shouldn't be thrown")
replaced it with just
whatever
as this makes the unexpected errors easier to debug, and the tests
would fail just as much and aren't rendered less readable.
Thanks Markus Holtermann for review
The primary use case is to interact with a third-party database (not
primarily managed by Django) that doesn't support time zones and where
datetimes are stored in local time when USE_TZ is True.
Configuring a PostgreSQL database with the TIME_ZONE option while USE_TZ
is False used to result in silent data corruption. Now this is an error.
