This makes it possible to run django.setup() in management commands that
don't need a settings module. In addition it simplifies error handling.
Thanks Claude for the review.
Made the fix in InteractiveMigrationQuestioner class code, rather than
MigrationAutodetector, because --dry-run shouldn't affect whether
MigrationAutodetector will detect non-nullable fields, but the
questioner should skip the question and returns a None for default
(since that won't be used anyway) if --dry-run is used.
`sort_dependencies` incorrectly interpreted 'complex' M2M relations
(with explicit through models) as dependencies for a model. This caused
circular complex M2M relations to be unserializable by dumpdata.
Thanks to aneil for the report and outofculture for initial tests.
Compare parameters instead of re.pattern instances, and add the other
parameters to the comparison. Also add a __ne__ to make assertNotEqual
work properly.
Avoided introducing a new regex-based SQL splitter in the migrations
framework, before we're bound by backwards compatibility.
Adapted this change to the legacy "initial SQL data" feature, even
though it's already deprecated, in order to facilitate the transition
to migrations.
sqlparse becomes mandatory for RunSQL on some databases (all but
PostgreSQL). There's no API to provide a single statement and tell
Django not to attempt splitting. Since we have a more robust splitting
implementation, that seems like a good tradeoff. It's easier to add a
new keyword argument later if necessary than to remove one.
Many people contributed to both tickets, thank you all, and especially
Claude for the review.
Refs #22401.
- Fixed bug in get_callable() that caused resolve() to put a string
in ResolverMatch.func.
- Made ResolverMatch.url_name match the actual url name (or None).
- Updated tests that used the string value in ResolverMatch.func, and
added regression tests for this bug.
- Corrected test urls whose dummy view paths caused failures (behavior
that was previously masked by this bug).
This is useful for tests manually calling migrate inside a testcase,
for normal usage this should make no difference, since there is no
surrounding transaction after all. If there is one we still try to
leave the transaction in a useable state (for postgres at least).
If this commit turns out to be causing issues, settings savepoint=False
is probably the right fix :)
The warning hint of `_check_test_runner` of 1.6 compatibility had a link
to a general release note. The link should be edited to refer the
relevant "Backwards incompatible changes in 1.6" section that documents
the cause and the possible solutions and workarounds of the warning.