[qa] Use in-memory DB for migration checks #186

[BelpHegoR17]

Use an isolated SQLite in-memory database when running the makemigrations --dry-run QA check.

Fixes #186

Checklist

• I have read the OpenWISP Contributing Guidelines.
• I have manually tested the changes proposed in this pull request.
• I have written new test cases for new code and/or updated existing tests for changes to existing code.
• I have updated the documentation.

Reference to Existing Issue

Closes #186.

Description of Changes

This PR updates the QA makemigrations --dry-run behavior to use an
isolated in-memory SQLite database instead of the default project
database. This avoids inconsistencies caused by local migration
history and ensures that migration checks run deterministically
regardless of the developer environment.

• Introduces an in-memory SQLite database for migration checking when
  OWQA_USE_IN_MEMORY_DB is enabled.
• Prevents migration checks from depending on user-specific DB state.

[nemesifier]

We'd have to do this in all the openwisp modules right @pandafy? Or else how would we accomplish this?

[stktyagi]

If I may.
I think we can avoid duplicating this in every module by adding a helper in openwisp_utils that checks for env var and returns the in-memory config. This way, modules can simply wrap their DATABASES setting with that helper.
If I'm missing something you or @pandafy can let me know.

[nemesifier]

@stktyagi wouldn't we have to edit the settings of every test project in each module anyway?

[stktyagi]

right the changes would be a little small but we would still need to atleast touch and go through every test settings, this makes me think of maybe using DJANGO_SETTINGS_MODULE to point to a dummy settings module in openwisp-utils which dynamically loads the current module settings into it and then overwrites the DATABASES variable dictionary. This whole process can be skipped either at the start or during variable overwriting using OWQA_USE_IN_MEMORY_DB keeping the modules completely untouched.
kind of like a proxy settings module.
what do you think?

[nemesifier]

That would hardly work because each module has different settings which are required for the module to start, unless we solve #408 first.

[stktyagi]

@nemesifier i may have explained it poorly, what i meant was this proxy wouldn't be a 'replacement' for module settings. Instead, it would use an environment variable (set by the QA tool) to dynamically import * from the module's actual settings.py first (using tests/manage.py we can get where the current settings.py are).

This ensures all mandatory, unique settings are loaded so the module can start. The proxy then only overwrites the DATABASES variable in memory.

i asked chatgpt to write a flow for this:-
QA Tool → Proxy Settings → Imports Real Settings (Module starts successfully) → Swaps Database Variable → Success.

[nemesifier]

It could work, if anyone wants to try to come up with a proof of concept we can evaluate whether the approach is really feasible

[BelpHegoR17]

@stktyagi While this could work in theory, Django settings often have side effects during import and some modules modify DATABASES themselves, which makes the proxy approach harder. It may also depend on more uniform settings across modules (as discussed in #408).

[coveralls]

coverage: 97.25%. remained the same
when pulling 253c810 on BelpHegoR17:issues/186-use-separate-db-for-migration-checks
into 37e9ffc on openwisp:master.