[Django] #34569: Unify all model fields to call get_prep_value from get_db_prep_value
Django
-------------------------------------+-------------------------------------
Reporter: Julie | Owner: nobody
Rymer |
Type: | Status: new
Uncategorized |
Component: Database | Version: 4.2
layer (models, ORM) |
Severity: Normal | Keywords:
Triage Stage: | Has patch: 0
Unreviewed |
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-------------------------------------+-------------------------------------
Following on #34539, should all fields that do not currently call
`get_prep_value` from `get_db_prep_value` be updated to call it so that we
have no more inconsistency with the
[https://docs.djangoproject.com/en/4.2/howto/custom-model-fields
/#converting-python-objects-to-query-values fields customization doc]?
Here is the list of all concerned fieldst:
- AreaField (contrib.gis)
- DistanceField (contrib.gis)
- ArrayField (contrib.postgres)
- DurationField
- UUIDField (this one even has a definition for `get_prep_value`, but it
is never called)
- ForeignKey (like previous one, possess definition for `get_prep_value`,
never called)
Please give me your thoughts or if I missed anything.
I for one am in favour of harmonising all field to follow the field API
(PS: wasn't sure about what ticket type this should be classified as)
--
Ticket URL: <https://code.djangoproject.com/ticket/34569>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
-------------------------------------+-------------------------------------
Type: | Status: new
Cleanup/optimization |
Component: Database layer | Version: 4.2
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* type: Uncategorized => Cleanup/optimization
Comment:
I knew that it'd open Pandora's box 😞 IMO we gain anything from adding:
{{{#!python
if not prepared:
value = self.get_prep_value(value)
}}}
to all these fields, but the community can decide otherwise. We have to be
very carefully with `ForeignKey` which has many subclasses.
> - UUIDField (this one even has a definition for `get_prep_value`, but it
is never called)
That's not true, see a [https://djangoci.com/view/%C2%ADCoverage/job
/django-
coverage/HTML_20Coverage_20Report/d_36b8140ab18a1a25___init___py.html#t2729
coverage report].
> - ForeignKey (like previous one, possess definition for
`get_prep_value`, never called)
That's not true, see a [https://djangoci.com/view/%C2%ADCoverage/job
/django-
coverage/HTML_20Coverage_20Report/d_36b8140ab18a1a25_related_py.html#t1154
coverage report].
--
Ticket URL: <https://code.djangoproject.com/ticket/34569#comment:1>
Django
-------------------------------------+-------------------------------------
Reporter: Julie Rymer | Owner: nobody
Type: | Status: new
Cleanup/optimization |
Component: Database layer | Version: 4.2
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Mariusz Felisiak):
Related [https://forum.djangoproject.com/t/model-fields-calling-get-prep-
value-from-get-db-prep-value/20947 discussion] on the forum.
--
Ticket URL: <https://code.djangoproject.com/ticket/34569#comment:2>
Django
-------------------------------------+-------------------------------------
Type: | Status: assigned
Cleanup/optimization |
Component: Database layer | Version: 4.2
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* owner: nobody => stimver
* status: new => assigned
--
Ticket URL: <https://code.djangoproject.com/ticket/34569#comment:3>
Django
-------------------------------------+-------------------------------------
Reporter: Julie Rymer | Owner: stimver
Type: | Status: assigned
Cleanup/optimization |
Component: Database layer | Version: 4.2
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Shaheed Haque):
Please see #34648 for a possible regression caused by #34539.
--
Ticket URL: <https://code.djangoproject.com/ticket/34569#comment:4>
Django
-------------------------------------+-------------------------------------
Reporter: Julie Rymer | Owner: stimver
Type: | Status: assigned
Cleanup/optimization |
Component: Database layer | Version: 4.2
(models, ORM) |
Severity: Normal | Resolution:
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* stage: Unreviewed => Accepted
Comment:
Tentatively accepted, but for concrete clases not as a rule. IMO, we
definitely shouldn't do this for `ForeignKey` and its subclasses.
--
Ticket URL: <https://code.djangoproject.com/ticket/34569#comment:5>
Django
-------------------------------------+-------------------------------------
Reporter: Julie Rymer | Owner: stimver
Type: | Status: assigned
Cleanup/optimization |
Component: Database layer | Version: 4.2
(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
-------------------------------------+-------------------------------------
* cc: Florian Demmer (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/34569#comment:6>