Opened 6 years ago

Closed 6 years ago

#29644 closed Bug (fixed)

String representation of SearchQuery gives inaccurate results

Reported by: Alex Krupp Owned by: Tom Forbes
Component: contrib.postgres Version: 2.0
Severity: Normal Keywords: SearchQuery search
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

For the purpose of writing tests, I'm trying to use the string representation of SearchQuery to see what query statements my querystring parser is generating.

When I do print(~SearchQuery('asdf')), instead of seeing "~SearchQuery('asdf')" I instead see "SearchQuery('asdf')". In other words, the tilde that is used to negate the SearchQuery isn't being shown.

Similarly, if I do:

query = SearchQuery('a') & ( SearchQuery('b') | SearchQuery('c') )

When I do print(query) I just see "SearchQuery('a') & SearchQuery('b') | SearchQuery('c')". The issue here is that the parentheses used to group these statements aren't shown, which again changes the meaning of this statement.

Change History (7)

comment:1 by Tim Graham, 6 years ago

Triage Stage: UnreviewedAccepted
Type: UncategorizedBug

It might be feasible to fix, I'm not sure.

comment:2 by Tom Forbes, 6 years ago

Owner: set to Tom Forbes
Status: newassigned

I've got a good fix for the negation, and a 'not sure if this a good idea' fix for the grouping. PR: https://github.com/django/django/pull/10276

For the grouping we could fix it quite elegantly by always surrounding CombinedSearchQuery's in (), but this would mean the example above would result in:

(SearchQuery('a') & SearchQuery('b') | SearchQuery('c'))

comment:3 by Alex Krupp, 6 years ago

That seems like a good fix to me. I don't foresee much use for this outside of writing tests. E.g. if you were going to log user searches so that they were viewable in the admin or whatever, presumably you'd log what the user typed rather than the parsed query. To the extent that you'd want to log the parsed queries I think it would only be for compliance purposes, but this would be fine for that since even with the parentheses you can still re-run the query and get the same results just by copying and pasting.

Last edited 6 years ago by Alex Krupp (previous) (diff)

in reply to:  3 comment:4 by Tom Forbes, 6 years ago

Replying to Alex Krupp:

That seems like a good fix to me. I don't foresee much use for this outside of writing tests. E.g. if you were going to log user searches so that they were viewable in the admin or whatever, presumably you'd log what the user typed rather than the parsed query. To the extent that you'd want to log the parsed queries I think it would only be for compliance purposes, but this would be fine for that since even with the parentheses you can still re-run the query and get the same results just by copying and pasting.

You might not be able to get the exact same results. One thing that's not easy to fix (as far as I can see) are the quotation marks. So in my example above it would more accurately be:

(SearchQuery(a) & SearchQuery(b) | SearchQuery(c))

I'm not sure if I like the extra parentheses around the query, it does make it harder to read. But on the other hand it does make the implementation simpler.

comment:5 by Tom Forbes, 6 years ago

Has patch: set

comment:6 by Carlton Gibson, 6 years ago

Triage Stage: AcceptedReady for checkin

comment:7 by Tim Graham <timograham@…>, 6 years ago

Resolution: fixed
Status: assignedclosed

In a3df757:

Fixed #29644 -- Made SearchQuery.str() reflect negation and grouping.

Note: See TracTickets for help on using tickets.
Back to Top