Support comparing SQL when order is not guaranteed in some statements.

Review Request #12040 — Created Feb. 4, 2022 and submitted — Latest diff uploaded

Information

Django Evolution
release-2.x

Reviewers

Django doesn't always generate SQL statements in a pre-defined order.
When adding or dropping multiple indexes, for example, it builds up
indexes as a set, and then iterates through them. This made
comparisons pretty unreliable.

We now pass the generated and expected SQL through a normalization
process. Sections of the expected SQL can be wrapped in a set, which
will then be sorted. The matching section of the generated SQL will be
sorted as well.

This is not perfect. If the generated SQL in that range is not a match,
it will still be sorted, and this can lead to some wonky results during
comparison. The "Generated SQL" output still uses the original generated
content, though, to help.

This also will not work quite right if Django ends up generating any
unordered SQL where each unordered item is actually a list of SQL
statements, but currently it doesn't appear that that's something that
happens. (Work was done to try to handle this case preemptively, but
it's far too complicated.)

Relevant series of statements has been updated to use this.

Unit tests pass for all supported versions of Python and Django.

Changes between revision 1 and 2

orig
1
2

Commits

Summary ID Author
Support comparing SQL when order is not guaranteed in some statements.
Django doesn't always generate SQL statements in a pre-defined order. When adding or dropping multiple indexes, for example, it builds up indexes as a `set`, and then iterates through them. This made comparisons pretty unreliable. We now pass the generated and expected SQL through a normalization process. Sections of the expected SQL can be wrapped in a `set`, which will then be sorted. The matching section of the generated SQL will be sorted as well. This is not perfect. If the generated SQL in that range is not a match, it will still be sorted, and this can lead to some wonky results during comparison. The "Generated SQL" output still uses the original generated content, though, to help. This also will not work quite right if Django ends up generating any unordered SQL where each unordered item is actually a list of SQL statements, but currently it doesn't appear that that's something that happens. (Work was done to try to handle this case preemptively, but it's far too complicated.) Relevant series of statements has been updated to use this.
62c5f10ef84e3980a178ce96c5e86041df4096e5 Christian Hammond
Support comparing SQL when order is not guaranteed in some statements.
Django doesn't always generate SQL statements in a pre-defined order. When adding or dropping multiple indexes, for example, it builds up indexes as a `set`, and then iterates through them. This made comparisons pretty unreliable. We now pass the generated and expected SQL through a normalization process. Sections of the expected SQL can be wrapped in a `set`, which will then be sorted. The matching section of the generated SQL will be sorted as well. This is not perfect. If the generated SQL in that range is not a match, it will still be sorted, and this can lead to some wonky results during comparison. The "Generated SQL" output still uses the original generated content, though, to help. This also will not work quite right if Django ends up generating any unordered SQL where each unordered item is actually a list of SQL statements, but currently it doesn't appear that that's something that happens. (Work was done to try to handle this case preemptively, but it's far too complicated.) Relevant series of statements has been updated to use this.
71e04bdc66ef6ad60fc51595dc060041221d55ca Christian Hammond
django_evolution/tests/base_test_case.py
Loading...