| Age | Commit message (Collapse) | Author |
|---|
|
Thanks guettli for the suggestion.
|
|
change_list_request.html doesn't exist, it's named change_list_results.html
|
|
This is provided as a new "validate_max" formset_factory option defaulting to
False, since the non-validating behavior of max_num is longstanding, and there
is certainly code relying on it. (In fact, even the Django admin relies on it
for the case where there are more existing inlines than the given max_num). It
may be that at some point we want to deprecate validate_max=False and
eventually remove the option, but this commit takes no steps in that direction.
This also fixes the DoS-prevention absolute_max enforcement so that it causes a
form validation error rather than an IndexError, and ensures that absolute_max
is always 1000 more than max_num, to prevent surprising changes in behavior
with max_num close to absolute_max.
Lastly, this commit fixes the previous inconsistency between a regular formset
and a model formset in the precedence of max_num and initial data. Previously
in a regular formset, if the provided initial data was longer than max_num, it
was truncated; in a model formset, all initial forms would be displayed
regardless of max_num. Now regular formsets are the same as model formsets; all
initial forms are displayed, even if more than max_num. (But if validate_max is
True, submitting these forms will result in a "too many forms" validation
error!) This combination of behaviors was chosen to keep the max_num validation
simple and consistent, and avoid silent data loss due to truncation of initial
data.
Thanks to Preston for discussion of the design choices.
|
|
|
|
|
|
Thanks martinogden for the initial patch and d1ffuz0r for tests.
|
|
|
|
MySQL accepts 0000-00-00 as a valid date but MySQLdb converts those
values into None. So there will be problems for instance if trying to
transport the data using dumpdata/loaddata.
This patch refs #6642 that has been closed as wontfix since this is a
particular problem of MySQL.
|
|
|
|
|
|
|
|
|
|
|
|
Thanks Erik Romijn.
|
|
|
|
The backwards-incompatible changes section wasn't structured in sections
like it is in release notes for previous versions.
|
|
|
|
|
|
|
|
Fixed an erroneous import in example code of docs (class-based-views/intro).
|
|
|
|
|
|
When the 'invalid' error message is set at field level, it masks
the error message raised by the validator, if any.
|
|
|
|
Model.save() will use UPDATE - if not updated - INSERT instead of
SELECT - if found UPDATE else INSERT. This should save a query when
updating, but will cost a little when inserting model with PK set.
Also fixed #17341 -- made sure .save() commits transactions only after
the whole model has been saved. This wasn't the case in model
inheritance situations.
The save_base implementation was refactored into multiple methods.
A typical chain for inherited save is:
save_base()
_save_parents(self)
for each parent:
_save_parents(parent)
_save_table(parent)
_save_table(self)
|
|
Thanks Ram Rachum for the report.
|
|
|
|
|
|
Thanks Anssi for haggling until I implemented this.
This change alleviates the need for atomic_if_autocommit. When
autocommit is disabled for a database, atomic will simply create and
release savepoints, and not commit anything. This honors the contract of
not doing any transaction management.
This change also makes the hack to allow using atomic within the legacy
transaction management redundant.
None of the above will work with SQLite, because of a flaw in the design
of the sqlite3 library. This is a known limitation that cannot be lifted
without unacceptable side effects eg. triggering arbitrary commits.
|
|
Thanks itsallvoodoo for the patch.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
There isn't much else to say, really.
|
|
|
|
Apparently django.db.transaction used to be an object.
|
|
Replaced them with per-database options, for proper multi-db support.
Also toned down the recommendation to tie transactions to HTTP requests.
Thanks Jeremy for sharing his experience.
|
|
|
|
Currently it only works in autocommit mode.
Based on @xact by Christophe Pettus.
|
|
Technically speaking they aren't usable yet.
|
|
It's synchronized with the autocommit flag.
|
|
Since "unless managed" now means "if database-level autocommit",
committing or rolling back doesn't have any effect.
Restored transactional integrity in a few places that relied on
automatically-started transactions with a transitory API.
|
|
This is mostly a documentation change.
It has the same backwards-incompatibility consequences as those
described for PostgreSQL in a previous commit.
|
|
|
|
enter_transaction_management() was nearly always followed by managed().
In three places it wasn't, but they will all be refactored eventually.
The "forced" keyword argument avoids introducing behavior changes until
then.
This is mostly backwards-compatible, except, of course, for managed
itself. There's a minor difference in _enter_transaction_management:
the top self.transaction_state now contains the new 'managed' state
rather than the previous one. Django doesn't access
self.transaction_state in _enter_transaction_management.
|
|
|
|
Fixed #20018
|
