Problem
The query string goes into the key in the order the client sent it, so ?a=1&b=2 and ?b=2&a=1 are two cache entries. This is documented, and the workaround is a custom key_builder. But it is a common need, and hand-written key builders are error-prone (see #230).
Proposal
Add an opt-in @cache(sort_query=True) that sorts the query parameters by name before building the key.
- Keep the original order of repeated values for the same name:
?tag=b&tag=a must stay distinct from ?tag=a&tag=b, since many apps treat that order as meaningful.
- Default stays
False, so existing keys and semantics are unchanged.
Problem
The query string goes into the key in the order the client sent it, so
?a=1&b=2and?b=2&a=1are two cache entries. This is documented, and the workaround is a customkey_builder. But it is a common need, and hand-written key builders are error-prone (see #230).Proposal
Add an opt-in
@cache(sort_query=True)that sorts the query parameters by name before building the key.?tag=b&tag=amust stay distinct from?tag=a&tag=b, since many apps treat that order as meaningful.False, so existing keys and semantics are unchanged.