Opened 3 years ago
Closed 3 years ago
#32951 closed Cleanup/optimization (fixed)
Remove Query.where_class in favor of using WhereNode directly.
| Reported by: | Nick Pope | Owned by: | Nick Pope |
|---|---|---|---|
| Component: | Database layer (models, ORM) | Version: | dev |
| Severity: | Normal | Keywords: | wherenode, where_class |
| 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
#6261 added support for customized WhereNode and QUERY_TERMS.
This was to "get GeoDjango working with the queryset-refactor branch" as it required a custom GeoWhereNode and being able to extend geographic lookup types.
QUERY_TERMS was removed in 244cc401559e924355cf943b6b8e66ccf2f6da3a for Django 2.1 with the intended replacement being the Lookup Registration API.
GeoWhereNode was removed in 3caf957ed5eaa831a485abcb89f27266dbf3e82b for Django 1.8, obsoleted by GISLookup.
Query.where_class is internal and undocumented and is propagated around through other methods signatures, e.g. .get_extra_restriction(), which is also internal and undocumented. We should be able to remove this no longer necessary complexity and use WhereNode directly.
Despite these being undocumented APIs, I don't know whether we want to go through a deprecation period?
Change History (4)
comment:1 by , 3 years ago
| Has patch: | set |
|---|
comment:2 by , 3 years ago
| Triage Stage: | Unreviewed → Accepted |
|---|
comment:3 by , 3 years ago
| Triage Stage: | Accepted → Ready for checkin |
|---|
PR