Django Evolution makes use of a large number of SQL statements that

generated SQL is compared against, one collection per supported

database. These were previously strings that were split up at comparison

time. In the test data these were often represented as lines that were

joined together into single strings.
Instead of doing the monotonous work of joining lists of strings into

single strings and then splitting again, we're now using lists of

strings everywhere. This is easier to maintain, eliminates subtle

problems encountered in the past (where a trailing comma on a string

from a copy/paste would result in a tuple, causing breakages), and

allows us to perform pattern matching.
Now, these statements can include a re.compile(...) in place of a

string in order to pattern match against generated SQL. While we always

prefer to perform exact matches, this is important for some upcoming

code that generates SQL containing a value made available by the

database itself that we cannot fake or safely influence.
If a regex is found, it triggers slightly-more-involved SQL comparisons,

but the output is generally the same.
To aid with all this, the assertion code that compares against these SQL

statements has been pulled out into an assertSQLMappingEqual()

statement, which some tests have been updated to use instead of trying

to perform their own normalization and assertions. These assertions are

now standardized and easy to bring into new tests in the future.

Unit tests pass for all database types on Python 2.7 and 3.8 on

Django 1.11 and 2.0.
Other versions were not tested as this code isn't very dependent on the

versions of the dependencies used.