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.
Backport of f287bec583 from master
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.
We need to make sure content read from the file is decoded from UTF-8
right from the start so Python doesn't try to use another encoding
(read: ASCII/CP1252 under Windows.)
Tim Graham
Markus Holtermann
Collin Anderson
Tim Heap
Carl Meyer
Tillmann Karras
Berker Peksag
Loic Bistuer
Claude Paroz
Raffaele Salmaso
Baptiste Mispelon
Huu Nguyen
Andrew Godwin
Moayad Mardini
Huu Nguyen
Russell Keith-Magee
Aymeric Augustin
Ramiro Morales
Loic Bistuer