combine repeated keys in Query.from_string

[Stephen Compall <stephen.compall@…>]

Query.to_string outputs something that can be massaged lightly into input to from_string, such as this:

status=accepted&status=assigned&status=new&status=reopened \
&reporter=stephen.compall&order=priority&col=id&col=summary \
&col=type&col=priority&col=component&col=provider

(where "
\n" is removed). However, giving this string to from_string will result in a query that only looks for status=reopened. The above status specification should be interpreted the same as status=accepted|assigned|new|reopened.

[Stephen Compall <stephen.compall@…>]

patch with unit testing

[Stephen Compall <stephen.compall@…>]

This patch alters from_string slightly, and adds a test that compares the SQL of equivalent query strings.

[Remy Blank]

Makes sense at first sight.

[Remy Blank]

The change you propose makes sense, but not for the reason you stated above. Indeed, Query.to_string() generates a query URL (note the leading ? and the modifier after the =), whereas Query.from_string() takes a query in query syntax (modifier before the =). So you can't just take the output from the former, and pass it to the latter. Or it seems you can, but it's by coincidence.

This subtle difference between the two syntaxes is quite error-prone, and I'm trying to unify them in #7699.

Still, your proposed change makes the following queries equivalent, which is a good thing IMO:

query:owner=somebody|somebody_else
query:owner=somebody&owner=somebody_else

Patch applied (with minor fix to the test case) in [7863]. Thanks!

[Remy Blank]

#8329 was closed as a duplicate.