#33647: bulk_update silently truncating values for size limited fields
-------------------------------------+-------------------------------------
Reporter: jerch | Owner: nobody
Type: Bug | Status: new
Component: Database layer | Version: 4.0
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by jerch):
Replying to [comment:4 Simon Charette]:
> An alternative approach might to commit to dropping the whole
`CASE`/`WHEN` wrapping altogether on backends that support it as described
in #29771.
Hmm, yes perfwise I totally agree - the UPDATE FROM VALUES variants are
much better for pumping tons of individual values. I already tried to
address that pattern in https://github.com/netzkolchose/django-fast-
update, with string formatting atm. The runtime numbers there speak for
themselves. But for a serious integration in the ORM there are some
obstacles to overcome:
- f-expressions wont work anymore (at least not without big workarounds)
- profound ORM integration needs serious rework on the update sql compiler
(or even a separate one just for the update + values pattern)
- depends on recent db engines (+distinction of mysql8 vs. mariadb)
Regarding f-expressions - idk if thats a biggie: `bulk_update` always
occured to me as an interface to pump individual values rather than doing
column trickery with it, so I would not mind, if that interface does not
support f-expressions anymore. But thats just me, if people insist on
using f-expressions here as well, this would need a workaround of unknown
complexity.
Imho the second point can be done, it just needs someone with time and
enough dedication (well I can try that, but would need serious help, as I
lack deeper knowledge of ORM internals).
The last point is more tricky - how to deal with older or incompatible
database engines here? Create a fallback (current implementation)? Or just
confront users with "nope, not supported here, get a newer/compatible db
engine"? It also raises the question, where to park the actually
implementation - while the ORM itself could blueprint the UPDATE FROM
VALUES pattern in ORM style, the backends would have to translate it into
their very own style, or even substyles for mysql (mysql8 != mariadb
here).
I guess that such a ground-shaking change to django would need some sort
of consensus first?
--
Ticket URL: <https://code.djangoproject.com/ticket/33647#comment:5>
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/010701804107f159-d0b01b94-ceaf-41e9-8277-169f744613a1-000000%40eu-central-1.amazonses.com.
