[Django] #22936: Get rid of field.get_db_prep

Django

unread,

Jul 2, 2014, 5:01:51 AM7/2/14

to django-...@googlegroups.com

#22936: Get rid of field.get_db_prep_lookup()
-------------------------------------+-------------------------------------
Reporter: akaariai | Owner: nobody
Type: | Status: new
Cleanup/optimization | Version: master
Component: Database | Keywords:
layer (models, ORM) | Has patch: 0
Severity: Normal | Needs tests: 0
Triage Stage: | Easy pickings: 0
Unreviewed |
Needs documentation: 0 |
Patch needs improvement: 0 |
UI/UX: 0 |
-------------------------------------+-------------------------------------
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 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.

--
Ticket URL: <https://code.djangoproject.com/ticket/22936>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

Django

unread,

Jul 2, 2014, 10:56:35 AM7/2/14

to django-...@googlegroups.com

#22936: Get rid of field.get_db_prep_lookup()
-------------------------------------+-------------------------------------
Reporter: akaariai | Owner: nobody
Type: | Status: new
Cleanup/optimization | Version: master

* stage: Unreviewed => Accepted

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 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.

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/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.

--

--
Ticket URL: <https://code.djangoproject.com/ticket/22936#comment:1>

Django

unread,

Apr 11, 2016, 9:59:10 PM4/11/16

to django-...@googlegroups.com

#22936: Get rid of field.get_db_prep_lookup()
-------------------------------------+-------------------------------------
Reporter: akaariai | Owner: nobody
Type: | Status: new
Cleanup/optimization |

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

unread,

Apr 12, 2016, 10:14:49 AM4/12/16

to django-...@googlegroups.com

#22936: Get rid of field.get_db_prep_lookup()
-------------------------------------+-------------------------------------
Reporter: akaariai | Owner: nobody
Type: | Status: new
Cleanup/optimization |

Comment (by Tim Graham <timograham@…>):

In [changeset:"1c30a6473df55c7efff71fd24f46c4b8d1ad5630" 1c30a647]:
{{{
#!CommitTicketReference repository=""
revision="1c30a6473df55c7efff71fd24f46c4b8d1ad5630"
Refs #22936 -- Moved IntegerField.get_prep_lookup() logic to lookups.
}}}

--
Ticket URL: <https://code.djangoproject.com/ticket/22936#comment:3>

Django

unread,

Apr 23, 2016, 4:04:04 PM4/23/16

to django-...@googlegroups.com

#22936: Get rid of field.get_db_prep_lookup()
-------------------------------------+-------------------------------------
Reporter: akaariai | Owner: nobody
Type: | Status: new
Cleanup/optimization |

Comment (by claudep):

[https://github.com/django/django/pull/6499 This PR] removes the
`get_prep_lookup` method.

--
Ticket URL: <https://code.djangoproject.com/ticket/22936#comment:4>

Django

unread,

Apr 25, 2016, 11:17:27 AM4/25/16

to django-...@googlegroups.com

#22936: Get rid of field.get_db_prep_lookup()
-------------------------------------+-------------------------------------
Reporter: akaariai | Owner: nobody
Type: | Status: new
Cleanup/optimization |

Comment (by Tim Graham <timograham@…>):

In [changeset:"1ba0b22a7a262e63cb7152ef3ab513660156d135" 1ba0b22]:
{{{
#!CommitTicketReference repository=""
revision="1ba0b22a7a262e63cb7152ef3ab513660156d135"
Refs #22936 -- Removed unused code in Field.get_db_prep_lookup().
}}}

--
Ticket URL: <https://code.djangoproject.com/ticket/22936#comment:5>

Django

unread,

May 2, 2016, 10:06:06 AM5/2/16

to django-...@googlegroups.com

#22936: Get rid of field.get_db_prep_lookup()
-------------------------------------+-------------------------------------
Reporter: akaariai | Owner: nobody
Type: | Status: new
Cleanup/optimization |

Comment (by Tim Graham <timograham@…>):

In [changeset:"eab5df12b664b154b2e280330aa43d8c0621b94a" eab5df1]:
{{{
#!CommitTicketReference repository=""
revision="eab5df12b664b154b2e280330aa43d8c0621b94a"
Refs #22936 -- Moved more of Field.get_db_prep_lookup() to lookups.
}}}

--
Ticket URL: <https://code.djangoproject.com/ticket/22936#comment:6>

Django

unread,

May 3, 2016, 8:48:39 PM5/3/16

to django-...@googlegroups.com

#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: 1 | Needs documentation: 0

Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Changes (by timgraham):

* has_patch: 0 => 1

Comment:

I submitted a PR to Claude's PR in comment:4 which completes the ticket.

--
Ticket URL: <https://code.djangoproject.com/ticket/22936#comment:7>

Django

unread,

May 4, 2016, 8:55:56 AM5/4/16

to django-...@googlegroups.com

#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: Ready for
| checkin

Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by timgraham):

* stage: Accepted => Ready for checkin

--
Ticket URL: <https://code.djangoproject.com/ticket/22936#comment:8>

Django

unread,

May 4, 2016, 2:03:44 PM5/4/16

to django-...@googlegroups.com

#22936: Get rid of field.get_db_prep_lookup()
-------------------------------------+-------------------------------------
Reporter: akaariai | Owner: nobody

Type: | Status: closed

Cleanup/optimization |
Component: Database layer | Version: master
(models, ORM) |

Severity: Normal | Resolution: fixed

Changes (by Claude Paroz <claude@…>):

* status: new => closed
* resolution: => fixed

Comment:

In [changeset:"388bb5bd9aa3cd43825cd8a3632a57d8204f875f" 388bb5b]:
{{{
#!CommitTicketReference repository=""
revision="388bb5bd9aa3cd43825cd8a3632a57d8204f875f"
Fixed #22936 -- Obsoleted Field.get_prep_lookup()/get_db_prep_lookup()

Thanks Tim Graham for completing the initial patch.
}}}

--
Ticket URL: <https://code.djangoproject.com/ticket/22936#comment:9>

Django

unread,

Oct 5, 2023, 9:26:14 AM10/5/23

to django-...@googlegroups.com

#22936: Get rid of field.get_db_prep_lookup()
-------------------------------------+-------------------------------------

Reporter: Anssi Kääriäinen | Owner: nobody
Type: | Status: closed
Cleanup/optimization |
Component: Database layer | Version: dev

Comment (by GitHub <noreply@…>):

In [changeset:"91cb2d0b487acc56d886612a7251b9ba555d71b4" 91cb2d0]:
{{{
#!CommitTicketReference repository=""
revision="91cb2d0b487acc56d886612a7251b9ba555d71b4"
Refs #22936 -- Doc'd Lookup.prepare_rhs.
}}}

--
Ticket URL: <https://code.djangoproject.com/ticket/22936#comment:10>

Django

unread,

Oct 5, 2023, 9:27:33 AM10/5/23

to django-...@googlegroups.com

#22936: Get rid of field.get_db_prep_lookup()
-------------------------------------+-------------------------------------

Comment (by Mariusz Felisiak <felisiak.mariusz@…>):

In [changeset:"6e7c8cc42e29bc14e7951977977bd510ff9dc3f5" 6e7c8cc]:
{{{
#!CommitTicketReference repository=""
revision="6e7c8cc42e29bc14e7951977977bd510ff9dc3f5"
[5.0.x] Refs #22936 -- Doc'd Lookup.prepare_rhs.

[Django] #22936: Get rid of field.get_db_prep_lookup()

Django

Django

Django

Django

Django

Django

Django

Django

Django

Django

Django

Django