MigrationRecorder now assumes that if the django_migrations table
doesn't exist, then no migrations are applied.
Reverted documentation change from refs #23808.
The new attribute is checked when the `migrate --fake-initial` option
is used. initial will be set to True for all initial migrations (this
is particularly useful when initial migrations are split) as well as
for squashed migrations.
The idea behind this change is, that AlterUniqueTogether,
AlterIndexTogether and AlterOrderWithRespectTo can always be moved after
an Add/Alter/Rename/RemoveField operation if they don't refer to the
respective field and are not empty sets / None.
Combined with the optimizations of duplicate AlterUniqueTogether,
AlterIndexTogether, and AlterOrderWithRespectTo operations from
128caa1e16, these operations are optimized
in a later round of the optimizer.
Thanks Tim Graham for the review.
Currently some of the migrations tests rely on the fact 'input' is aliased
because of six, instead of using mock.patch. Replace this code with proper
use of mock.patch.
Also, replace one case of excessively specific python version check with
testing six.PY3
This is preferrable to writing in the current working directory because
it eliminates the risk to leak unwanted files, which can result in very
weird test failures.
Also this will help if we ever try to run these tests concurrently.
Previously Django only checked for the table name in CreateModel
operations in initial migrations and faked the migration automatically.
This led to various errors and unexpected behavior. The newly introduced
--fake-initial flag to the migrate command must be passed to get the
same behavior again. With this change Django will bail out in with a
"duplicate relation / table" error instead.
Thanks Carl Meyer and Tim Graham for the documentation update, report
and 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.
This is the result of Christopher Medrela's 2013 Summer of Code project.
Thanks also to Preston Holmes, Tim Graham, Anssi Kääriäinen, Florian
Apolloner, and Alex Gaynor for review notes along the way.
Also: Fixes#8579, fixes#3055, fixes#19844.
Got rid of AppConfig._stub. As a side effect, app_cache.app_configs now
only contains entries for applications that are in INSTALLED_APPS, which
is a good thing and will allow dramatic simplifications (which I will
perform in the next commit). That required adjusting all methods that
iterate on app_configs without checking the "installed" flag, hence the
large changes in get_model[s].
Introduced AppCache.all_models to store models:
- while the app cache is being populated and a suitable app config
object to register models isn't available yet;
- for applications that aren't in INSTALLED_APPS since they don't have
an app config any longer.
Replaced get_model(seed_cache=False) by registered_model() which can be
kept simple and safe to call at any time, and removed the seed_cache
argument to get_model[s]. There's no replacement for that private API.
Allowed non-master app caches to go through populate() as it is now
safe to do so. They were introduced in 1.7 so backwards compatibility
isn't a concern as long as the migrations framework keeps working.
This commit is a refactoring with no change of functionality, according
to the following invariants:
- An app_label that was in app_configs and app_models stays in
app_config and has its 'installed' attribute set to True.
- An app_label that was in app_models but not in app_configs is added to
app_configs and has its 'installed' attribute set to True.
As a consequence, all the code that iterated on app_configs is modified
to check for the 'installed' attribute. Code that iterated on app_models
is rewritten in terms of app_configs.
Many tests that stored and restored the state of the app cache were
updated.
In the long term, we should reconsider the usefulness of allowing
importing models from non-installed applications. This doesn't sound
particularly useful, can be a trap in some circumstances, and causes
significant complexity in sensitive areas of Django.
Since the original ones in django.db.models.loading were kept only for
backwards compatibility, there's no need to recreate them. However, many
internals of Django still relied on them.
They were also imported in django.db.models. They never appear in the
documentation, except a quick mention of get_models and get_app in the
1.2 release notes to document an edge case in GIS. I don't think that
makes them a public API.
This commit doesn't change the overall amount of global state but
clarifies that it's tied to the app_cache object instead of hiding it
behind half a dozen functions.
Tim Graham
Дилян Палаузов
Mads Jensen
Melvyn Sopacua
Marti Raudsepp
Michiel Beijen
chillaranand
Claude Paroz
Aymeric Augustin
Sebastian Spiegel
Lex Berezhny
za
Joseph Kahn
Zbigniew Siciarz
Jim Nicholls
Alex Hill
Raphael Gaschignard
Iacopo Spalletti
Jarek Glowacki
Berker Peksag
Attila Tovt
Scott Sexton
Pankrat
Hasan
Niels Van Och
Jon Dufresne
Markus Holtermann
Dražen Odobašić
Jeremy Satterfield
Caio Ariede
mlavin
Andrei Kulakov
Curtis Maloney
John Giannelos
Marten Kenbeek
Aymeric Augustin
Collin Anderson
Tim Heap
Carl Meyer
Tillmann Karras
Loic Bistuer
Raffaele Salmaso
Baptiste Mispelon
Huu Nguyen
Andrew Godwin
Moayad Mardini
Huu Nguyen
Russell Keith-Magee