Opened 10 years ago
Last modified 15 months ago
#22936 closed Cleanup/optimization
Get rid of field.get_db_prep_lookup() — at Initial Version
| Reported by: | Anssi Kääriäinen | Owned by: | nobody |
|---|---|---|---|
| Component: | Database layer (models, ORM) | Version: | dev |
| Severity: | Normal | Keywords: | |
| Cc: | Triage Stage: | Ready for checkin | |
| Has patch: | yes | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description
The field.get_db_prep_lookup() method is used to do preparation of a plain Python value for given lookup. Looking at the coding of get_db_prep_lookup() the get_db_prep_lookup() is doing work that belongs into the lookup itself.
The same goes also for get_prep_lookup(). It seems that get_prep_lookup() is either doing something that should actually be done in get_prep_value(), or something that belongs into lookups.
If a custom field needs to do different kind of preparation for some lookups (something that can't be done in get_[db_]prep_value(), it can always provide a lookup subclass that does the right thing for that field type. An example is IntegerField and 'lt' and 'gte' lookups. Providing custom subclasses might be laborious to do if there are a lot of different lookup types that need custom preparation. For that reason a hook for custom fields could still be useful.
Even if we want to left get_db_prep_lookup and get_prep_lookup hooks for custom fields, the base coding belongs into the lookups themselves. Currently the fields are doing work that clearly belongs to the lookup itself.