Opened 2 years ago
Last modified 7 months ago
#34569 assigned Cleanup/optimization
Unify all model fields to call get_prep_value from get_db_prep_value
| Reported by: | Julie Rymer | Owned by: | stimver |
|---|---|---|---|
| Component: | Database layer (models, ORM) | Version: | 4.2 |
| Severity: | Normal | Keywords: | |
| Cc: | Florian Demmer | Triage Stage: | Accepted |
| Has patch: | no | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description
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 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)
Change History (5)
comment:1 by , 2 years ago
| Type: | Uncategorized → Cleanup/optimization |
|---|
comment:3 by , 2 years ago
| Owner: | changed from to |
|---|---|
| Status: | new → assigned |
comment:5 by , 2 years ago
| Triage Stage: | Unreviewed → Accepted |
|---|
Tentatively accepted, but for concrete clases not as a rule. IMO, we definitely shouldn't do this for ForeignKey and its subclasses.
comment:6 by , 7 months ago
| Cc: | added |
|---|
I knew that it'd open Pandora's box 😞 IMO we gain anything from adding:
to all these fields, but the community can decide otherwise. We have to be very carefully with
ForeignKeywhich has many subclasses.That's not true, see a coverage report.
That's not true, see a coverage report.