Linter should fail, or at least warn, when ran against an unsupported vendor

[vanschelven]

When the linter is run against an unsupported database vendor, it will happily try to do its job using the generic BaseAnalyser

Given the heavy use of analysis of SQL statements, this seems an overly optimistic approach, which will lead to hard to debug problems. Better to just fail outright and tell the user about the misconfiguration.

In particular, I ran into this when doing my analysis against sqlite3, and wondering why using an AddDefaultValue from the django-add-default-value package doesn't do its magic (i.e. making the linter succeed).
The answer is: because that package does nothing in the case of sqlite3 (which is probably what you want, so that you can use the code from that package in testing environments as well as production ones). Which means that the generated sql does not contain the strings that the present package searches for.

[David-Wobrock]

Hi @vanschelven

On the general aspect of warning/failing when the migration linter is ran against an unsupported DB sounds like a good idea. In theory, the base analyser should be able to handle the basic cases, as long as the target DB uses standard SQL statements - but a warning is not a bad idea 👍

On the specific case that AddDefaultValue from the eponymous package didn't achieve the expected behaviour, it seems that it doesn't support sqlite. Additionally, even when adding a column with a default value (a default constraint known by the DB) on sqlite, it is expected for the linter to reject this migration.
Indeed, as you might be able to see in this comment, when adding a column to an existing table, the behaviour for sqlite is to create a new table, copy the data to the new table and swap the tables. Even with a default constraint, the linter currently considers this behaviour backward incompatible.

[vanschelven]

I have to admit that I already noticed that AddDefaultValue doesn't support sqlite, but in my mind silently ignoring the migration was the desired behavior in that case. My implicit reasoning was: when using sqlite, you're in some testing/development environment, and actually have no need for the defaulting behavior, because multiple code-bases accessing the same database is simply not a scenario that comes up for such environments.

On second thought, however, I realise that there the mapping (development <=> sqlite) may often occur in practice but is by no means absolute. Given that there are still scenarios (such as mine) in which silent ignoring is in fact fine, so outright crashing is not desired, I will file an issue to raise a warning in that package also.

On the general aspect of warning/failing when the migration linter is ran
against an unsupported DB sounds like a good idea. In theory, the base
analyser should be able to handle the basic cases, as long as the target DB
uses standard SQL statements - but a warning is not a bad idea +1

Yeah... sqlite is probably the outlier here with its full regeneration of tables for any change, so I'm tempted to go with warning too.