Figure out data migrations #4

bochecha · 2019-06-24T14:09:40Z

Right now, event handlers can define their custom model to store data in them. The tables are created before running Azafea, with the initdb command.

However, if an existing model needs to change its schema, then we would have no way other than moving its current data to a different table, then running initdb again and finally moving the old data into the new table with an ad-hoc script.

We can probably do something better with Alembic, adding a new migrate command which would run the migrations of all the models associated to configured queues.

This will also require some documentation:

the page about how to write custom handlers will need some additions for writing migrations;
the deployment page will need to cover how to run migrations.

The text was updated successfully, but these errors were encountered:

Queue handlers usually come with their data models. Up until now, the only way to create them was through the initdb command, which only works to create new models, but not to modify existing ones. This commit sets up Alembic and adds a new `make-migration` command, which will try to understand the model for a queue handler and generate a migration script. Relates to #4

Queue handlers usually come with their data models. Up until now, the only way to create them was through the initdb command, which only works to create new models, but not to modify existing ones. This commit adds a new `migratedb` command, which will find the migrations of all configured queues and run them to upgrade the database. Relates to #4

Queue handlers usually come with their data models. Up until now, the only way to create them was through the initdb command, which only works to create new models, but not to modify existing ones. This commit sets up Alembic and adds a new `make-migration` command, which will try to understand the model for a queue handler and generate a migration script. Relates to #4

Queue handlers usually come with their data models. Up until now, the only way to create them was through the initdb command, which only works to create new models, but not to modify existing ones. This commit adds a new `migratedb` command, which will find the migrations of all configured queues and run them to upgrade the database. Relates to #4

Queue handlers usually come with their data models. Up until now, the only way to create them was through the initdb command, which only works to create new models, but not to modify existing ones. This commit sets up Alembic and adds a new `make-migration` command, which will try to understand the model for a queue handler and generate a migration script. Relates to #4

Queue handlers usually come with their data models. Up until now, the only way to create them was through the initdb command, which only works to create new models, but not to modify existing ones. This commit adds a new `migratedb` command, which will find the migrations of all configured queues and run them to upgrade the database. Relates to #4

bochecha · 2019-12-09T16:44:52Z

This was fixed by #59

bochecha added the enhancement New feature or request label Jun 24, 2019

bochecha mentioned this issue Aug 12, 2019

Add a composite index on ping country + created_at #26

Closed

bochecha closed this as completed Dec 9, 2019

bochecha mentioned this issue Dec 9, 2019

cli: Allow creating follow-up migrations #60

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Figure out data migrations #4

Figure out data migrations #4

bochecha commented Jun 24, 2019

bochecha commented Dec 9, 2019

Figure out data migrations #4

Figure out data migrations #4

Comments

bochecha commented Jun 24, 2019

bochecha commented Dec 9, 2019