#33647: bulk_update and bulk_create silently truncating values for size limited
fields on postgres
-------------------------------------+-------------------------------------
Reporter: jerch | Owner: Rowan
| Douglas
Type: Bug | Status: assigned
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 Simon Charette):
Hello Rowan, absolute no worries about the delayed answer, glad to see you
are still interested in working on this ticket!
You're fully caught up yes. The `bulk_create` data loss issue introduced
in 5.2 was fixed by d6ae2ed868e43671afc4d433c3d8f4d27f7eb555 and the
`parametrized` solution should be explored to resolve `bulk_update` (and
other problems in distinct tickets). I'll provide you some context but it
is not meant to be prescriptive, just some verbose pointers to reduce the
feedback cycles and get you started.
Here's how a commit breakdown could look like
1. Introduce `Field.db_type(parametrized=True)`. This will likely require
a deprecation shim in `Fied.__init_subclass__` that warns if an override
doesn't confom to the new signature and wraps the override with a function
that accepts `parametrized` and ignores it as well as documentation and
tests for the adjusted `Field` subclasses (e.g
[https://github.com/django/django/pull/20300/changes#diff-
35c61cb049d39b2e890f12f8c1f9583fb8ca351a8495718b5375a7120f775d05R185
here's how something like that can be achieved]). I think a definition
time warning is preferable as to avoid costly signature check and warnings
at query compilation time.
2. Adjust the logic added in d6ae2ed868e43671afc4d433c3d8f4d27f7eb555 to
make use of this new `parametrized=False` paramter instead of mangling the
SQL returned by `Field.db_type`
3. Introduce `Cast(parametrized=True)`, document and test.
4. Adjust `bulk_update`'s `Cast` to pass `parametrized=False`
That's already a significant chunk of work but if you fancy once 2. lands
you could also work on a more adequate data type over
1378d665a1c85897d951f2ca9618b848fdbba2e7 for Postgres field alterations.
I think Jacob's comment was referring to the last part of comment:2
regarding `ArrayField`. I think this case will be fixed by 1. as long we
make sure to percolate `parametrized` to `self.base_field.db_type` in it's
`db_type`
[https://github.com/django/django/blob/158fd81ef5a5647d27eb3065063284f9ee0a3ca4/django/contrib/postgres/fields/array.py#L116
implementation].
Lastly I'll include a few extra findings I stumbled upon while reviewing
my comment.
- While `Field.cast_db_type` is not documented I think it should follow
the same treatment as `.db_type` regarding a deprecation shim when
introducing `parametrized`
- It looks like `RangeContainedBy.process_rhs`
[https://github.com/django/django/blob/158fd81ef5a5647d27eb3065063284f9ee0a3ca4/django/contrib/postgres/fields/ranges.py#L278-L279
could also benefit] from `parametrized=False`
--
Ticket URL: <https://code.djangoproject.com/ticket/33647#comment:43>
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 visit
https://groups.google.com/d/msgid/django-updates/0107019c887ddbd8-6876f7ea-973b-4c0e-86b5-111400e66ce4-000000%40eu-central-1.amazonses.com.
