#28344: Add for_update parameter to Model.refresh_from_db()
-------------------------------------+-------------------------------------
Reporter: Patryk Zawadzki | Owner: (none)
Type: New feature | Status: new
Component: Database layer | Version: dev
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Description changed by Raphael Michel:
Old description:
> To provide some additional perspective with some real-world use cases:
>
> I agree that there is no use case for `skip_locked` here, and for `of`
> only with model inheritance (which I never used). I do see a theoretical
> use-case for `nowait`, but I have never come across wanting it in real
> code.
>
> I have come across wanting a `refresh_for_update`-style thing as
> discussed here many times, though. As others mentioned, usually in
> relation with an encapsulated piece of business logic that gets passed an
> instance and requires locking. Sure, the business logic could just
> acquire a new version of that instance, but then the code calling the
> business logic needs to know that the instance it passed into the
> business logic no longer is a valid version and *also* needs to refresh
> their instance, which is not an intuitive interface.
>
> In at least some situation, I even built my own little `refresh_from_db`
> within my own code, which certainly is not nice:
>
> https://github.com/pretix/pretix/blob/40cdb0c5077ae34b56e0263cfcf87c3558a1d042/src/pretix/base/models/orders.py#L1797-L1814
>
> So I'm +1 for adding *something* that helps with this, and I'd personally
> think a new `refresh_for_update(using, fields, of, nowait)` function is
> the clearest and most future-safe design.
New description:
I have a project where we deal with many financial operations that rely on
transactions and row-level locking a lot to guard against race conditions.
Unfortunately it's a common pattern for a function to accept an instance
of model A, start an atomic block, fetch a new instance of the same row
with `select_for_update()`, do a change, call `save()` and then refresh
the original instance. It would all be easier if I could just call
`instance.refresh_from_db(for_update=True)` and it would save a me a DB
roundtrip to refresh the original instance passed (Django ORM does not
have a session manager so the old object will not otherwise reflect the
changes).
--
--
Ticket URL: <https://code.djangoproject.com/ticket/28344#comment:29>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/0107018c57ff1755-e31adb16-d903-41e3-bb9c-7b450639eb7f-000000%40eu-central-1.amazonses.com.
