# Generic single-database configuration.

## Migrations
When generating migrations, the database models (**/database/models.py) should be edited with the desired modifications.
After that, automatic migration scripts can be generated by executing:
```bash
alembic revision --autogenerate -m "<name of the revision>"
```
However, autogenerate can't detect:
* Changes of table name. These will come out as an add/drop of two different tables, and should be hand-edited into a name change instead.
```
def upgrade():
    alembic.op.rename_table('old_name', 'new_name')
```
* Changes of column name. Like table name changes, these are detected as a column add/drop pair, which is not at all the same as a name change.
* Anonymously named constraints. Give your constraints a name, e.g. UniqueConstraint('col1', 'col2', name="my_name"). See the section The Importance of Naming Constraints for background on how to configure automatic naming schemes for constraints.
* Special SQLAlchemy types such as Enum when generated on a backend which doesn’t support ENUM directly - this because the representation of such a type in the non-supporting database, i.e. a CHAR+ CHECK constraint, could be any kind of CHAR+CHECK. For SQLAlchemy to determine that this is actually an ENUM would only be a guess, something that’s generally a bad idea. To implement your own “guessing” function here, use the sqlalchemy.events.DDLEvents.column_reflect() event to detect when a CHAR (or whatever the target type is) is reflected, and change it to an ENUM (or whatever type is desired) if it is known that that’s the intent of the type. The sqlalchemy.events.DDLEvents.after_parent_attach() can be used within the autogenerate process to intercept and un-attach unwanted CHECK constraints.

When performing migrations, we have two options: online and offline. 
If we do an online migration, (alembic upgrade head), we execute the migration against the database. 
If we do an offline migration, (alembic upgrade head --sql) we just generate the sql script which can then later be manually executed on the database.
The app will automatically try to apply the migrations (alembic upgrade head) when running if the configuration db -> apply_migrations is set to **true**.

Every autogenerated migration script should be carefully reviewed.