This PR fixes Docker images not building properly. This was a two-parter issue.
The first issue stemmed from the fact that the alembic models now pull in the starting level from the config file which didn't exist when the Docker image was being built. I fixed this issue by making the Dockerfile cp config.example.yml config.yml, alembic upgrade head, and then rm config.yml after migrations were done.
The second issue was caused by the fact that SQLite does not support ALTER operations. A previous alembic migration introduced a drop_column function call which is a syntax error in SQLite. This is solved by switching env.py over to using batch migrations with render_as_batch=True which can be read about here but essentially just creates a new table with the desired migrations and then copies the old data over.
There is a slight alembic revision rollback because I decided to merge the last 4 migrations (the migrations that were created after the initial breaking drop_column one) into one new one after enabling batch migrations (these only apply towards future revisions, not retroactively) which fixed the Docker build image issue. I don't see this to be a big deal because we're so early in development and things can be subject to break change at any time and migrating to batch migrations by hand would have been a pain that slowed development more than this issue already has.
This PR fixes Docker images not building properly. This was a two-parter issue.
The first issue stemmed from the fact that the alembic models now pull in the starting level from the config file which didn't exist when the Docker image was being built. I fixed this issue by making the Dockerfile
cp config.example.yml config.yml,alembic upgrade head, and thenrm config.ymlafter migrations were done.The second issue was caused by the fact that SQLite does not support ALTER operations. A previous alembic migration introduced a
drop_columnfunction call which is a syntax error in SQLite. This is solved by switchingenv.pyover to using batch migrations withrender_as_batch=Truewhich can be read about here but essentially just creates a new table with the desired migrations and then copies the old data over.There is a slight alembic revision rollback because I decided to merge the last 4 migrations (the migrations that were created after the initial breaking
drop_columnone) into one new one after enabling batch migrations (these only apply towards future revisions, not retroactively) which fixed the Docker build image issue. I don't see this to be a big deal because we're so early in development and things can be subject tobreakchange at any time and migrating to batch migrations by hand would have been a pain that slowed development more than this issue already has.