In the next 3 weeks, we will make significant changes to the DB migration generation mechanism. Lately, we’ve seen an increased number of errors related to migrations when altering the DBMS schema. Our current implementation, created back in 2020, heavily relies on running the application in our cloud infrastructure, as well as the sequence of version generation.
We are moving migrations from code generators to Studio. After the update, every time the Save button (or Push in newer versions with CRDT) is pressed in the Studio DBMS designer, it will automatically create and save a migration for subsequent inclusion in the generated backend applications. This solution has a number of side effects:
- The number of migrations for each application will increase, slightly enlarging the binary size (previously migrations were “bulk” after each successful deployment).
- If you delete a field or model, save the schema, and then add a field or model with the same name hoping to preserve data in the DBMS - it will not work. The migration will record 2 queries - first to delete, and then to create.
- The amount of computations when saving the DB schema will increase, but if it becomes significant, we have workaround to make migration generation asynchronous, not blocking the saving of the schema.
Benefits - significantly more stable and predictable migration generation, the ability to view the current set of migrations, and possibly even manually edit them. Additionally, this will allow us to create build-only deployment plans for clients who host applications on their own servers.