Alternatively we could also set the column to have a default value so when the field is updated/created, the default gets automatically populated.
FYI in case anyone missed it, database schema and data migrations will be coming in our v4 version. We briefly mentioned it in our StrapiConf keynote and v4 teaser:
2 Likes
@DMehaffy I haven’t done any work with Strapi in a few months as the contract I was using it for ended. I saw your last message about migrations via the email digest and just wanted to pop in to add 
Trust me when I say, I have been fighting for the entire Strapi community to ensure we get proper database schema migrations native to Strapi 
5 Likes
Hi, I wanted to drop a radical dea regarding the migrations. It should be possible to store the schema in the format that is used by Prisma (https://www.prisma.io/docs/concepts/components/prisma-schema). Adding a field would mean updating the Prisma schema. This means outsourcing the entire data storage to Prisma, which supports migrations already. It also means you automatically benefit from all the Prisma features (which is typescript based).
1 Like
This idea is really really good! I also tried out Prisma a few days ago and it’s the best ORM i have ever used so far (better than Django ORM, Ruby on Rails, Hibernate and more.
The only problem that I see here is the connection between Prisma and Strapi. We would have to use the Prisma core to read and write models into the schema.prisma because one is able to create and modify models via the UI, which should reflect in the schema.prisma file.
So the idea is really good but the implementation is unfortunately not straight forward.
1 Like
Thanks @bykof :-). I’m intending to try out this use-case in a manual way:
- I will update the prisma schema whenever a field is added in the .settings.json file
- I want to test if this indeed allows me to access the data both via the strapi api and the prisma api
A potential benefit that I’m very interested in is improved separation between content data and application data. If I understand correctly, every field in the .settings.json file is shown in the strapi admin. Ideally, certain fields that are pure application data (and which an editor should not touch) should not be shown there. If I add these fields only to the prisma schema (and then migrate the database), I should have them properly separated. It crossed my mind to maintain completely separate tables (e.g. FooContentData controlled by strapi and FooApplicationData controlled by prisma) that are joined on an id field, but this would complicate the setup quite a lot.
Will it clean the databases when we change the field names? I just saw it is still a problem in Strapi.
That’s the plan 
1 Like
Thanks for you sharing. I also did the similar things to delete / rename the fields in order to clean up some fields.
But you will meet a problem in this case.
Let’s use the same case you mentioned : we rename a field via strapi.
- Strapi automatically make a new field “description”, and the old field “text” is kept because strapi will not delete fields.
- And we write knex migration file to delete this “text” fields.
Everything should work in our development environment or any server where ALREADY has the database setup with previous schema (i.e. the table has “text” field)
What if a new engineer join our project / we deploy this repo to a new server ?
- strapi will construct database according to the current model definition (i.e. “description” field, but will not create the “text” field )
- then the knex migration is executed, but there is no “text” field in the database, so it will throw error.
I am not sure what should I do to solve this workaround at the moment.
If strapi is implementing this feature, I will suggest that feature can be similar to Django migration mechanism. It was mentioned in one of the comments above as well. The database schema changes should be kept as every migration, so the database construction is executed from the 1st version of our database definition, and then other modfications.
1 Like
We are using Strapi and Next JS to create a CMS app and we fetch data via GraphQL. We have local db and we generate the pgsql file after making strapi changes. We provide this file to the Devops team and ask them to dump in the database for test env. Now, let’s say someone goes into the Strapi instance of test environment and makes some changes. How can we sync the test1 changes with the local db? Can someone guide on this?
You can ask the devops team to take a dumpfile of the database that the test environment is connected to, using a command like the following:
mysqldump -u username -ppassword databaseName > dumpfile.sql
Then you have to import the dumpfile.sql file into your local db with a command like the following:
mysql -u username -ppassword localDatabaseName < dumpfile.sql
** Note that if the users have uploaded any kind of assets in the test environment and you are using the default plugin provider, meaning that the uploads are saved in public/uploads, you have to take a copy of the uploads folder as well and copy it into your local instance.
It’s already in the v4, we haven’t completely documented custom migrations but you can see my example for it in v4 here: GitHub - derrickmehaffy/strapi-example-v4-custom-db: Example Strapi v4 app showing how the custom v4 migrations work
There is an autoMigration in the v4, and eventually we plan to have a way to dump it’s actions to files instead of just running the actions so other systems could execute them.
4 Likes
great, thanks, when do you plan to document it?
When the API is considered stable for this, at the moment it’s unstable (manual migrations).
The automated migrations has really no documentation other than how to disable it. Once we add the file dump mechanism then we will add some docs for that. For the bulk of use-cases the automated system should handle everything for you.
1 Like
Hi, I’m using Strapi 4 and trying to create migration scripts. For sqlite it’s ok, but when I’m using postgres db I’m getting the error while running the app 'db.getConnection(…).transaction is not a function. Any ideas what’s the problem?
Another reason to have a native migration tool.
1 Like
And news on this? I have a lot of issues migration my local database schema changes to production.
1 Like
Hi,
Do you have any update on this.