#22936: Get rid of field.get_db_prep_lookup()
-------------------------------------+-------------------------------------
Reporter: akaariai | Owner: nobody
Type: | Status: new
Cleanup/optimization |
Component: Database layer | Version: master
(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
-------------------------------------+-------------------------------------
Old 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
> [https://github.com/django/django/blob/master/django/db/models/fields/__init__.py#L655
> 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
> [https://github.com/django/django/blob/master/django/db/models/fields/__init__.py#L1717
> 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 leave 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.
New 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
[https://github.com/django/django/blob/b29316c54bb3465265ff931e807229f13349457d/django/db/models/fields/__init__.py#L749-L783
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
[https://github.com/django/django/blob/0247c9b08f8da4a2d93b9cede6c615011552b55a/django/db/models/fields/__init__.py#L1878-L1881
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 leave `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.
--
Comment (by timgraham):
As suggested in the ticket description, I did the small step of moving
`IntegerField.get_prep_lookup()` to lookup subclasses:
[https://github.com/django/django/pull/6444 PR].
--
Ticket URL: <https://code.djangoproject.com/ticket/22936#comment:2>
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 post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/066.22c66a576bfaec80ccb53627282ab529%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
