On 13 joulu, 22:11, Emil Stenström <e...@kth.se> wrote: > I just thinking out loud here but: what if another thread does something to > the previously loaded object? I'm not sure if Django has concurrency tests > build into the test suite, but if it hasn't it could explain why the code > is written as it is.
I have added tests for concurrent delete + save. I have also updated the patch in other respects. Some polish done, and docs added. The patch can be found from https://github.com/akaariai/django/compare/model_save_refactor. It should be commit-ready. I hope somebody has time to check the altered .save() coding - the save_base is split into save_base, _save_parents, _save_table, _do_update and _do_insert. This splitting isn't necessary for the UPDATE, if not updated, INSERT behavior, but it cleans up the code, and it also allows for some nice things when combined with customizable model ._state. See ticket https://code.djangoproject.com/ticket/19396 for the model._state part. The custom _state classes allow for tracking model's dirty fields and updating automatically only those, true updatable primary keys and optimistic locking. The two first are implemented in tests for the ticket, see https://github.com/akaariai/django/compare/model_state_improvements#L6R0. The patch isn't yet rebased onto latest revision of model_save_refactor. - Anssi -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
