In that case, the content of INSTALLED_APPS will be ignored until it's
fixed and the autoreloader kicks in. I confirmed this behavior manually.
As explained on the ticket it's hard to write a test for this case
Backport of df0a446f from master.
Pickling a `SimpleLazyObject` wrapping a model did not work correctly; in
particular it did not add the `_django_version` attribute added in 42736ac8.
Now it will handle this and other custom `__reduce__` methods correctly.
Backport of 35355a4ffe from master
This commits lifts the restriction that the outermost atomic block must
be declared with savepoint=False. This restriction was overly cautious.
The logic that makes it safe not to create savepoints for inner blocks
also applies to the outermost block when autocommit is disabled and a
transaction is already active.
This makes it possible to use the ORM after set_autocommit(False).
Previously it didn't work because ORM write operations are protected
with atomic(savepoint=False).
Backport of 91e9f1c from master
Too much field exclusions in form's construct_instance() in _post_clean()
could lead to some unexpected missing ForeignKey values.
Fixes a regression from 45e049937. Refs #13776.
Backport of 65a1055a3 from master.
Moved data loss check when assigning to a reverse one-to-one relation on
an unsaved instance to Model.save(). This is exactly the same change as
e4b813c but for reverse relations.
Backport of c3904de from master
With this change, it's expected to survive anything except errors
that make it impossible to import the settings. It's too complex
to fallback to a sensible behavior with a broken settings module.
Harcoding things about runserver in ManagementUtility.execute is
atrocious but it's the only way out of the chicken'n'egg problem:
the current implementation of the autoreloader primarily watches
imported Python modules -- and then a few other things that were
bolted on top of this design -- but we want it to kick in even if
the project contains import-time errors and django.setup() fails.
At some point we should throw away this code and replace it by an
off-the-shelf autoreloader that watches the working directory and
re-runs `django-admin runserver` whenever something changes.
Backport of fe6ddb837d from master
Ensured squashed migrations are recorded as applied when the
migrate command is run and all of the original migrations
have been previously applied.
Backport of 69db1c7455 from master
Django ignores the value of the TEMPLATE_* settings if TEMPLATES is also
set, which is confusing for users following older tutorials. This change
adds a system check that warns if any of the TEMPLATE_* settings have
changed from their defaults but the TEMPLATES dict is also non-empty.
Removed the TEMPLATE_DIRS from the test settings file; this was marked
for removal in 1.10 but no tests fail if it is removed now.
Backport of 24620d71f2 from master
Thanks João Silva for reporting the problem and Tim Graham for finding the
problematic RE and for review.
This is a security fix; disclosure to follow shortly.
The session record is now only created if/when the session is modified. This
prevents a potential DoS via creation of many empty session records.
This is a security fix; disclosure to follow shortly.
Commit 15f82c7 ("used pyinotify as change detection system when
available") introduced a regression where editing a file in vim with
default settings (writebackup=auto) no longer causes the dev server
to be restarted. On a write, vim moves the monitored file to a backup
path and then creates a new file in the original. The new file is not
monitored as it has a different inode. Fixed this by also watching for
inotify events IN_DELETE_SELF and IN_MOVE_SELF.
Backport of e5cfa394d7 from master
