Still I am really concered about manual migration and the automigration of strapi.
I see here following problem:
I want to write a migration to inject some data into my application.
Let’s say I have following model:
-
Notes
description
Now I write a migration with knex:
exports.up = function(knex) {
return knex('notes').insert([
{
description: 'my first note',
},
{
description: 'my second note',
},
]);
}
exports.down = function(knex) {
return knex('notes').del();
}
This migration should run after strapi started, because then the field exists in the database, thanks to strapi automigration.
Now I want to rename the field from description to text.
I create the field in the notes.settings.json or add it via the content-type manager and delete the created column in the database.
Then i write following migration:
exports.up = function(knex) {
return knex.schema.table('notes', (table) => {
table.renameColumn('description', 'text');
})
}
exports.down = function(knex) {
return knex.schema.table('notes', (table) => {
table.renameColumn('text', 'description');
})
}
This migration should run before strapi starts otherwise it would create the field before hand and the migration would fail, because there is already an existing migration.
By writing this problem I found the solution.
One could use seed files with knex:
knex seed:run
The seed file from the 1st. migration would look like following:
exports.seed = function (knex) {
return knex("area").insert([
{
areaId: "MyNewAreaId",
name: "My first area",
},
{
areaId: "MySecondAreaId",
name: "My second area",
},
]);
};
Edit: Ok problem here is that the run of seed files isn’t stored in the database, so that knex doesn’t know if a seed was already executed or not.
So seeds are used only for first time data inserting.
Maybe a first “rule” could be derived.
Migrations should always run before strapi starts up, seeds should always run once and after strapi starts up.