Order of parameters pass to __in lookup affected by de-duplication.

[Nick Pope]

After the fix for ticket #25544, the order of parameters passed to the __in lookup is affected by the de-duplication using set().

This results in the generated query being unstable between different runs of the python interpreter due to hash seed randomisation.

[Nick Pope]

​PR

[Tim Graham]

What practical problem did you encounter? I'm surprised that the order of items in an IN clause would matter much.

[Nick Pope]

Replying to Tim Graham:

What practical problem did you encounter? I'm surprised that the order of items in an IN clause would matter much.

Heh. I get the feeling that I'm going to get shot down here (and I know and understand the reasons why).

I've inherited some code that currently and for the foreseeable future depends on the output of the query generated by Query.sql_with_params().
It executes it via pandas.DataFrame.read_sql_query() and also uses this to generate a cache key. Because the parameter ordering is unstable, this affects the key generation.

Regardless of the horrors of this, the issue looks like a regression to me - the previous behaviour changed unexpectedly. I can understand if you'd like to only apply this to master, however.

[Carlton Gibson]

I'd be happy with the use of OrderedSet here. Semantically in uses a set but we (always/mostly?) pass it a list, which is ordered, and it's reasonable enough to maintain that. (Beyond Nick's usage, it could be handy somewhere.)

Is this a regression? Was it always part of the contract? Not sure. Pass. :)

[Tim Graham <timograham@…>]

In b0fbfae0:

Fixed #29503 -- Made in lookup keep order of values in query.

Regression in 86eccdc8b67728d84440a46e5bf62c78f2eddf6d.

[Tim Graham <timograham@…>]

In 16e691d:

[2.1.x] Fixed #29503 -- Made in lookup keep order of values in query.

Regression in 86eccdc8b67728d84440a46e5bf62c78f2eddf6d.

Backport of b0fbfae09334554124e1dccb7559d10f36e2f84c from master