I'm migrating an existing TypeORM + PostgresQL project from TypeORM to Prisma. This existing project was handling migrations with Flyway: I wrote the SQL scripts to change the DB and those script were executed against de DB via Flyway. Now that I'm using prisma, I would like to take advantage of prisma migration. However, I would still like to have full control of the migrations, and to that extent, I would like to keep using Flyway. My idea was to generate the SQL files with prisma and then use Flyway to run them against de DB. What I've read so far, is that prisma cannot be used to just generate migrations (it will run them eventually, even if I use the --create-only flag, as discussed in here). I found in the help of prisma cli the prisma migrate diff command and I saw that it receives two urls to compare the schemas of two databases and generate de diff as an SQL file. I was wondering if there is something like prisma migrate diff that receives a url and a schema.prisma file so I can generate the diff using the url to my DB and my current schema file. Or is there any other way to just generate prisma migrations without executing them?
Now, that is what I would prefer. In case there is no way to just generate prisma migrations, I think it's fine to use it to run the migrations. However, I'm a little concerned on possible conflicts between the Flyway migrations that have been executed in the past and the new prisma migrations. I know both of them create tables in the DB to keep track of the migrations and Flyway's and Prisma's table should be different, so there should be no problems. But I don't feel confident about this. Has anyone migrate from Flyway to Prisma than can give me some advise on this? Or can I just ignore Flyway migrations.
I was wondering if there is something like prisma migrate diff that receives a url and a schema.prisma file so I can generate the diff using the url to my DB and my current schema file
Yes. You can point prisma migrate diff to your Prisma schema as the "to" state and your DATABASE_URL as the "from" state as follows:
npx prisma migrate diff \
-—from-schema-datamodel ./prisma/schema.prisma # path to your Prisma schema
-—to-url $DATABASE_URL # enviroment variable
-—script diff-migration.sql
You can then create a flyway migration using the generated SQL from prisma migrate diff.
You can learn more about the different arguments prisma migrate diff accepts in our CLI reference. Don't hesitate to let me know if you hit a snag. :)
Related
I have a user's schema: name, age, etc...
A user signs up in production,
I then decide I'd also like to capture "email" and save it in the User's table.
but since the previous records didn't have the email rece, prisma will want me to reset database
is there any walk around to prevent this database reset when migrating in prisma.js
A workaround might be manually adding a new field into your database, then introspecting your database, meaning pulling database structure in your prisma schema. After adding the field in your table, run npx prisma db pull. This should update your Prisma schema file. You might also need to regenerate prisma client using npx prisma generate.
Please also look here and here
I have been using AWS Cloudformation and Terraform to manage cloud infrastructure as code (IAC). The benefits are obvious.
1) Template file to concisely describe your infrastructure
2) Versioning
3) Rollbacks
I also have a PostgreSQL DB where I can dump the schema into a single file. Now, it would be amazing if I could edit a dumped SQL file like I do a (IFC) template. I could then validate my new SQL template and apply changes to my DB with the same workflow as Cloudformation or Terraform.
Does anyone know if a tool like this exists for any of the various SQL providers?
Have you given Flyway a try?
It supports versioning database migrations as well as rolling back and undoing migrations when needed. It also keeps a schema table in the database that tracks which migrations have been applied to that database, so that you can continuously deploy new scripts and changes to an existing application that is using Flyway.
We are planning to migrate from Flyway to Liquibase.
Although Liquibase provides an option "generateChangeLog" that will output the xml changelog needed to create the database.
However we are looking to convert each of our script individually to xml , i.e each versioned script of flyway will become a versioned change set.
If done manually, it is going to be a tedious process, So we are looking forward to some automated solution for the same.
There is no way to migrate from flyway to liquibase but you can keep on one side flyway history in your souce files and begin with a diffChangeLog to initialize your liquibase from production environnement.
This way you have old history in your flyway scripts nd new history in liquibase
I have a set of scripts that build a database using knex. What is the minimum effort possible to build this database or get the SQL for building it? I do not have Node.js set up for myself and I am new to both Node.js and Knex, but I do know SQL.
What is the minimum effort possible to build this database or get the
SQL for building it?
Your 2 options are either:
Install Node on your local machine (very simple see: link), and run the scripts against a local database (may or may not be simple depending on the amount of environment setup required.). Then you can use your DB to dump the table creation SQL if you want to build the tables on a different database.
Review the Knex scripts and reverse engineer them. The Knex table creation functions are not complicated to understand, and you can reference the Knex API here.
I would recommend giving #1 a try, and if it takes you more than an hour or 2, then just do #2, unless there are 50-ish or more tables, then work your way through #1 anyway.
PS: If you run the Knex scripts, you can also turn on debugging in the knex connection configuration, and the SQLs being executed will be output to the console.
I follow code first approach to generate my databases by EFCore.
Now during development one of my models changed. How can I update the corresponding database tables on a live system at one of our customers? I do not want to dump or delete any data of course.
I'm still on .NET Core 1.1.0.
I fear you'll have to swallow the pill then.
Database.EnsureCreated() is only useful for developing, where you don't have to preserve data. If you have to preserve data or change the table schema, you have to use migrations or database scaffolding (create models from Database schema).
In any case, do a backup of the production data, before applying/attempting following steps and try it out upfront on a staging server.
One touchy option would be...
restore your code (i.e. going back to an older revision in your VCS)
create a table layout based on it (running Add-Migration InitialVersion or dotnet ef migrations add InitialVersion followed by Update-Database or dotnet ef database update
reapply your model changes (going back to your current revision in VCS, but keeping the files in the Migration folder)
run Add-Migration ModelUpdateV2 or dotnet ef migrations add ModelUpdateV2
run Script-Migration (Thanks #Smit!) or dotnet ef migrations script. This will generate an SQL command for applying the changes to the schema
From now on you have two options:
Look for a __EFMigrationHistory table within your database on the development database. It should contain one entry with your initial migration name. Export this table into your production system. Then you application should apply the migrations on the next start (when you call context.Database.MigrateAsync() within your Startup.cs).
From now on you should be able to use migrations in future
Just execute the migration script from above, without copying over __EFMigrationHistory, but then you'll have to repeat the steps above.
The other option is, to always create the models from the database (see dotnet ef dbcontext scaffold command (see EF Core Docs) do create models from database schema in future.
Then every time you change the table, you have to create your own SQL for migration and apply that before or while deploying the application.