To the best of my understanding, since populate_models() is now called
as soon as Django starts, it cannot be called while a models module is
being imported, and that removes the need for postponing.
(If hell breaks loose we'll revert this commit.)
Refs #21681.
Since it triggers imports, it shouldn't be done lightly.
This commit adds a public API for doing it explicitly, django.setup(),
and does it automatically when using manage.py and wsgi.py.
Thanks Florian for isolating the shortest way to reproduce this issue:
./runtests.py \
django.contrib.auth.tests.test_context_processors.AuthContextProcessorTests.test_perms_attrs \
django.contrib.auth.tests.test_auth_backends.ChangedBackendSettingsTest.test_changed_backend_settings \
django.contrib.auth.tests.test_auth_backends.CustomUserModelBackendAuthenticateTest.test_authenticate \
django.contrib.auth.tests.test_basic.BasicTestCase.test_createsuperuser_management_command
SQLite accepts the relevant standard SQL (although by default it doesn't
enforce the constraint), and the 'traditional' creation backend helper
generate it, so this allows us to:
- Maintain the status quo
- Improve readability of the SQL code generated for that backend.
Also, we will need this for when we fix Refs #14204.
Returning None on errors required unpythonic error checking and was
inconsistent with get_app_config.
get_model was a private API until the previous commit, but given that it
was certainly used in third party software, the change is explained in
the release notes.
Applied the same change to get_registered_model, which is a new private
API introduced during the recent refactoring.
ContentTypes are only created for installed applications, and I could
make a case for not returning a model that isn't installed any more.
The check for stale ContentTypes in update_contenttypes doesn't use
model_class.
ModelSignal actually needs get_registered_model since the lookup happens
at import time. I took this opportunity to perform a small refactoring.
This removes the gap between the master app registry and ad-hoc app
registries created by the migration framework, specifically in terms
of behavior of the get_model[s] methods.
This commit contains a stealth feature that I'd rather not describe.
This is to provide a consistent interface (namely bytes) for the smtp
backend which after all sends bytes over the wire; encoding with as_string
yields different results since mails as unicode are not really specified.
as_string stays for backwardscompatibilty mostly and some debug outputs.
But keep in mind that the output doesn't match as_bytes!
Made it use 'AUTOINCREMENT' suffix for PK creation. This way it doeesn't
regress when compared with the 'traditional' DB backend creation
infrastructure.
Refs #10164.
The last component of the dotted path to the application module is
consistently referenced as the application "label". For instance it's
AppConfig.label. appname could be confused with AppConfig.name, which is
the full dotted path.
register_model is called exactly once in the entire Django code base, at the
bottom of ModelBase.__new__:
new_class._meta.apps.register_model(new_class._meta.app_label, new_class)
ModelBase.__new__ exits prematurely 120 lines earlier (sigh) if a model with
the same name is already registered:
if new_class._meta.apps.get_registered_model(new_class._meta.app_label, name):
return
(This isn't the exact code, but it's equivalent.)
apps.register_model and apps.get_registered_model are essentially a setter and
a getter for apps.all_models, and apps.register_model is the only setter. As a
consequence, new_class._meta.apps.all_models cannot change in-between.
Considering that name == new_class.__name__, we can conclude that
register_model(app_label, model) is always called with such arguments that
get_registered_model(app_label, model.__name__) returns None.
Considering that model._meta.model_name == model.__name__.lower(), and looking
at the implementation of register_model and get_registered_model, this proves
that self.all_models[app_label] doesn't contain model._meta.model_name in
register_model, allowing us to simplify the implementation.
It raises ImportError whenever an entry in INSTALLED_APPS points
(directly or indirectly via AppConfig.name) to a non-existing module
and ImproperlyConfigured in all other cases.
Catching ImportError and re-raising ImproperlyConfigured tends to make
circular imports more difficult to diagnose.
Previously the _apps/models_loaded flags could remain set to False if
set_installed_apps exited with an exception, which is going to happen as
soon as we add tests for invalid values of INSTALLED_APPS.
* Introduced [un]set_installed_apps to handle changes to the
INSTALLED_APPS setting.
* Refactored [un]set_available_apps to share its implementation
with [un]set_installed_apps.
* Implemented a receiver to clear some app-related caches.
* Removed test_missing_app as it is basically impossible to reproduce
this situation with public methods of the new app cache.
It was not used inside Django, is not tested or documented. Consequently
remove without deprecation path.
Thanks to @vajrasky for bringing it to our attention.
Currently such overrides aren't reflected in the app cache.
It would be possible to handle them. But that doesn't look like a very
good API. It makes it complicated to express "add this app" and "remove
this app", which are the most common operations on INSTALLED_APPS.
- Tested consistency the current app_configs instead of INSTALLED_APPS.
- Considered applications added with _with_app as available.
- Added docstrings.
Took this opportunity to change get_app[s] to only consider applications
containing a model module as that seems slightly more backwards compatible.
Since callers that care about models pass only_with_models_module=True,
this has very few consequences. Only AppCommand needed a change.
Adjusted several tests that used it to add apps to the app cache and
then attempted to remove them by manipulating attributes directly.
Also renamed invalid_models to invalid_models_tests to avoid clashing
application labels between the outer and the inner invalid_models
applications.
It was called _populate() before I renamed it to populate(). Since it
has been superseded by populate_models() there's no reason to keep it.
Removed the can_postpone argument of load_app() as it was only used by
populate(). It's a private API and there's no replacement. Simplified
load_app() accordingly. Then new version behaves exactly like the old
one even though it's much shorter.
First stage imports app modules. It doesn't catch import errors. This
matches the previous behavior and keeps the code simple.
Second stage import models modules. It catches import errors and retries
them after walking through the entire list once. This matches the
previous behavior and seems useful.
populate_models() is intended to be equivalent to populate(). It isn't
wired yet. That is coming in the next commit.
Since applications that aren't installed no longer have an application
configuration, it is now always True in practice.
Provided an abstraction to temporarily add or remove applications as
several tests messed with app_config.installed to achieve this effect.
For now this API is _-prefixed because it looks dangerous.
Florian Apolloner
Aymeric Augustin
Ramiro Morales
Claude Paroz
ijl
Preston Timmons
Tim Graham
Jon Lønne
Alex Gaynor
Levi Gross
Jonas Gastal
Curtis
Marc Tamlyn