So the whole topic is really complex if you start to work on it… here are some problematic points that I see:
- If we implement a migration plan for Strapi, what do we do with the existing models? For example all the models of strapi-admin or strapi-upload… Surely we can create a “starting” migration, but this will lead also to pretty hard problems
- Strapi Models and Strapi Migrations should go hand in hand, there is no opt in… If you create a model over the interface there should be always a migration created otherwise this will lead to inconsistency. For example if I create a model with the UI strapi creates me a table in the database. Now add some field X to the model. Now I want to rename X in Y. At this point Strapi would create just the field Y and leave X as it is. Now I would write a migration to copy all data from X to Y. After that I delete the field X with another migration. And here is the problem: If I setup a new server with this strapi models and migrations this would create an error. Strapi would create all fields automatically, so the model with field Y is created. The field X would never have been created and therefore the migrations would become useless.
- The best example for migrations are Django Migrations. You write a new model. After that you run:
./manage.py createmigrationsthen django will compare the model with the database and will create an automatic generated migration for you unless there are questions. And here comes the nice stuff: If you want to have a new field which is not nullable you surely have to define a default value. You can define it over the CLI or programmatically, but Django tries really to automate all the stuff as far as it is able to do so. - First we have to define what we really need. I think for now it’s really hard to fulfill all interests. We should talk about following points:
- what is the purpose of migrations in strapi?
- what is realistic?
- what fits into the strapi ecosystem?
Cheers guys, looking forward to read from you 