Windows support

[olivierdalang]

This translates shell scripts to python, so migrations can be run on windows too.

I tested it locally. Some notes/comments/questions:

• On the test DB, sigip views must be dropped manually (otherwise pre-all fails with cannot drop view qwat_od.vw_export_pipe because other objects depend on it). What is the status of these views ? Is it normal that pre-all does not drop them and post-all recreate them ?

• Before merging this, we should make CI work again, as otherwise it's too risky to do this type of work (see https://github.com/qwat/qwat-data-model/issues/348)

• Also, before this is usable, another blocker must be fixed: https://github.com/qwat/qwat-data-model/issues/353

[3nids]

On the test DB, sigip views must be dropped manually (otherwise pre-all fails with cannot drop view qwat_od.vw_export_pipe because other objects depend on it). What is the status of these views ? Is it normal that pre-all does not drop them and post-all recreate them ?

I think we should not have views in extra schemas in the test DB. They might need to be removed?

Before merging this, we should make CI work again, as otherwise it's too risky to do this type of work

Indeed. @ponceta is there any plan here?

Also, before this is usable, another blocker must be fixed: https://github.com/qwat/qwat-data-model/issues/353

@ponceta would you look to this one too?

[ponceta]

To make things right I would propose as guidelines from experience:

• [ ] export views must ALL be in an export schema (qwat_export) (like QGEP)
• [ ] custom views must not reference export views (avoid locks as much as possible)
• [ ] documentation and process should take into account a few custom views as examples -> rewrite some (not all) of the sigip views into custom views