Django

Code

Ticket #2271 (closed: fixed)

Opened 2 years ago

Last modified 2 years ago

__exact is only optional for top level queries

Reported by: russellm Assigned to: russellm
Milestone: Component: Database wrapper
Version: SVN Keywords: __exact query
Cc: Triage Stage: Unreviewed
Has patch: 0 Needs documentation: 0
Needs tests: 0 Patch needs improvement: 0

Description

Django documentation states that:


If you don't provide a lookup type -- that is, if your keyword argument doesn't contain a double underscore -- the lookup type is assumed to be exact.

For example, the following two statements are equivalent:

Blog.objects.get(id=14)
Blog.objects.get(id__exact=14)

This is for convenience, because exact lookups are the common case.


While this is true for the provided example, it is not true for joined queries:

Blog.objects.get(author__id=14)
Blog.objects.get(author__id__exact=14)

The second query works - the first one fails because "id" is not a valid query term.

The fault appears to be in the code in parse_lookup that does pk 'faking' of queries - this code relies upon a query size of 1 to determin the assumed __exact, which fails if there are multiple query terms.

Attachments

Change History

06/30/06 07:07:25 changed by jacob

So should the query parser just append "exact" if the last word isn't a lookup type?

06/30/06 21:38:51 changed by russellm

Yes, that is what I am suggesting. There are some edge cases where this will fail with models that have query terms as field names, but these edge cases would continue to work as long as queries were fully expressed.

06/30/06 22:14:34 changed by russellm

  • status changed from new to closed.
  • resolution set to fixed.

(In [3248]) Fixes #2271 -- Added code to imply __exact on any query argument that doesn't finish with a known query term.


Add/Change #2271 (__exact is only optional for top level queries)




Change Properties
Action