On 3/14/19 10:52 AM, Adam Johnson wrote:
> Assuming the application is not using either a transaction or
> select_for_update(), current Django does still guarantee that either the
> complete state after Process 1 or 2 is in the database, by always writing
> back all the fields. That is, no Photo in
I want to qualify this by saying that personally I've always thought of
(and likely will continue to think of) model objects as a snapshot of
what's in the database, and use the more explicit queryset.update() when
that snapshot is NOT what I want to save back to the database. So I may be
somewhat
+1 to what Adam said. Turning this feature on by default would be certainly
cause a lot of bugs in application
expecting a "coherent state" to be persisted on .save().
That would effectively make most of the Form.clean(), Model.clean() and DRF
serializer logic in charge of
validating a field val
I'm not sure if a global setting is a good idea. Code in third-party apps
would need to work with both configurations?
On Thursday, March 14, 2019 at 8:39:05 AM UTC-4, Daniel Tao wrote:
>
> I agree with this:
>
> > Therefore it seems like it would be a breaking change which is hard to
> communic
I agree with this:
> Therefore it seems like it would be a breaking change which is hard to
communicate to users, a complicated situation.
This is why I'm recommending that this behavior be opt-in via a Django
setting such as SAVE_UPDATE_DIRTY_FIELDS_ONLY. Application developers would
then nee
I believe there's the opportunity for a subtle bug in applications if
Django moves from its current default behaviour of saving all fields to
saving only dirty fields. Values in a model instance can become "torn"
between two versions by two concurrent processes even though neither wanted
to do this
That's a +1 from me. I've certainly hit the bugs you've mentioned before,
and I can't think of a good reason not to do dirty field tracking,
especially if it were to be opt in.
Bikeshedding a little bit, rather than having a global setting, I'd rather
see an option on Options/Meta so that opt i
While I'm not sure I have any particular suggestion for this, the problem
is important enough for a few of the projects I'm maintaining. I have
implemented more than a few custom save() methods,
post_init/pre_save/post_save signals and complicated ways of setting
update_fields and acting on their v
I feel conflicted here as I've spent numerous hours under different
contracts fixing bugs caused by missing update_fields and leading to data
loss or inconsistent database states ;)
On a more serious note, please make this happen.
With concurrent updates calling save() without update_fields is as
