At lauchtime, the app uses tables defined in SetupService to populate the database. These tables must exist. They are used both in development and production. They must be located under IMPORT_PATH (defaults to server/import, or specify in .env file). See CLI Flask setuphere.
These tables are somewhat specific to a given instance, i.e. one might want to change one or more tables for a given instance, add rows, modify entries after startup, etc. and as such do not constitute something we want to version control. But we may eventually want to provide examples of such tables.
However problems may arise when e.g. we modify the data model, and add/remove columns to these tables. Although this is very much specific to what is changed, in general it is not easy to integrate these changes in a simple alembic migration.
A clear and concise description of todo items.
I'd like to find a solution, in particular to ease alembic migrations, but not at the cost of a big refactor, or a more complex setup.
For now, the most sensible solution is to write good migration scripts, and use data/import tables if necessary. We should add some documentation regarding this and the import tables.
Aims/objectives.
At lauchtime, the app uses tables defined in
SetupService
to populate the database. These tables must exist. They are used both in development and production. They must be located underIMPORT_PATH
(defaults to server/import, or specify in .env file). See CLIFlask setup
here.These tables are somewhat specific to a given instance, i.e. one might want to change one or more tables for a given instance, add rows, modify entries after startup, etc. and as such do not constitute something we want to version control. But we may eventually want to provide examples of such tables.
However problems may arise when e.g. we modify the data model, and add/remove columns to these tables. Although this is very much specific to what is changed, in general it is not easy to integrate these changes in a simple alembic migration.
A clear and concise description of todo items.
I'd like to find a solution, in particular to ease alembic migrations, but not at the cost of a big refactor, or a more complex setup.