I'm using prisma and deploying it to fly.io. I deleted the migrations in the prisma/migrations folder. When I run prisma migrate deploy it still applies the migrations that I deleted. How do I delete the _prisma_migrations table in order to completely get rid of the deleted migrations?
Use the sqlite3 terminal.
Open the terminal by using the command sqlite3
Then use the DROP TABLE _prisma_migrations; command
Related
I use this boilerplate app to learn NestJs GITHUB LINK. The template is amazing but there was one thing that I can't fix migrations. When I try to add a new entity or use an existing one with npm run migrate:create Init migration was successful
Migration D:/src/database/migrations/1657796180301-init.ts
has been generated successfully.
but without any updating on the migration file or database. Only If I use synchronize: true and start the app the database was updated.
try to run migration:generate to generate new migrate file.
You have to run migration:run to apply migrations. This process is not done automatically because some migrations will cause you to loose data (dropping a column for example), so this gives you a chance to validate migration file before applying it.
When I write Script-Migration on Visual Studio console, It creates a file called uhftsodk.sql that contains something like this:
CREATE TABLE IF NOT EXISTS "__EFMigrationsHistory" (
"MigrationId" character varying(150) NOT NULL,
"ProductVersion" character varying(32) NOT NULL,
CONSTRAINT "PK___EFMigrationsHistory" PRIMARY KEY ("MigrationId")
);
I am a Windows user, but the production environment I am trying to implement is an Ubuntu 20.04 vm, with PostgreSQL.
I run this script in PostgreSQL from Ubuntu and it generated the table called "__EFMigrationsHistory"
But, What else am I supposed to do from there?
I want to create all my tables I used in Visual Studio for this particular project. I am using PostgreSQL for both scenarios, and it is working on development (using add-migration name and update-database) but not working in production...
The problem was I deleted the migrations, so when I run Script-Migration from Package Manager Console, it did not create all the tables, just the __EFMigrationsHistory table...
So, I created a new migration again, and then run Script-migration. Now the file was completed.
Take a look at the CLI commands dotnet ef migrations script and dotnet ef database update.
CLI commands can be run in any environment (Windows and Linux). You would generally script the migrations first, then review the script, then test the script, then backup the production database and then apply the script to the production database.
If this does not answer your question, please go into more details, where the problem for you lies. (The question has been asked a bit vague.)
I just made a migration file.sql to add a new table to the database, and I ran the flywayMigrate command sbt flywayMigrate. Now I realised I missed adding two columns to the same table. I have an option to write another migration, but I don't want to increase the number of migrations when I can rollback and change the migration I just made to create a table and add two more columns to it. Can you tell me how do I rollback some number of migrations and change them, and run sbt flywayMigrate again?
You don't necessarily have to re-run whole migration. There's a table which flyway uses for metadata and I think it is called schema_version. You can set the last applied migration id (there are some hashes to be set IIRC, but you will be able to figure them from error messages, if they don't match) and flyway would pick up from there.
As described in Flyway FAQ rollback scripts are not supported.
You have options to:
restore your database from backup
drop and recreate the database rerunning all the migration scripts
manually rollback the migration and remove its record from metadata table
Before anyone marks this as a duplicate, none of the questions similar to this addressed any of my concerns or answered any of my questions.
I am currently developing all the POCOs and data contexts in a library project, and running migrations from within this project. The database I'm updating is the development database.
What do I do if I want to create the current schema to a fresh, new database? I figure that all I have to do is to change the connection string in web.config and run Update-Database, correct?
While the live/production database is up and running, I want to add new columns and new tables to the schema, and test it out in development. So I switch back the connection string to the development database's connection string, and run Update-Database.
Going back and forth between two databases seems like I'll get conflicts between _MigrationHistory tables and the auto-generated migration scripts.
Is it safe to manually delete the _MigrationHistory tables in both databases, and/or delete the migration files in /Migrations (so I'll run Add-Migration again)? How do we manage this?
What do I do if I want to create the current schema to a fresh, new database?
- Yes, to create fresh database to the current migration level you simply modify the connection string to point to a database that does not yet exist and run update-database. It will run all the migrations in order.
As far as migrating to the Production database, I am running the update-database command with the -script switch to acquire the raw sql and then applying that script to the production database manually. This is helpful if you need to keep a record of sql commands run against the database as well. Additionally, you can generate the script explicitly from a specific migration to another specific migration via some of the other update-database switches.
Alternatively, you can create an Idempotent script that works from any migration by using the–SourceMigration $InitialDatabase switch and optionally specify an end migration with –TargetMigration
If you delete the _MigrationHistory tables you will have issues where the generated script will be trying to add columns that already exist and such.
You may find the following link helpful:
Microsoft Entity Framework Migrations
I would suggest having a separate trunk in your source code repository - one pointing to production and one to development to avoid risks of switching between the two in visual studio.
Me also had the same problem, even when using one and the same database - due to some merges in the repository, and the mix of automatic/manual migrations. For some reason the EF was not taking into account the target database, and calculating what scripts need to me executed, based on what is already in the database.
To fix this, I go to the [__MigrationHistory] table on the target database and get the latest migration name. This will help EF to determinate the state of the DB, and will execute just the scripts needed.
then the following script is run:
update-database -script -sourcemigration {latest migration name}
This creates update script that is specific to the target database (the connection string should be correct, as discussed in the other comments)
you can also use -force parameter if needed
this way you can update any database to latest version, no mater in what version you found it, if it has MigrationHistory table.
Hope this helps
My production and my developmental database went out of synch and it gave me endless problems. I solved it using a tool from Red-Gate to match up the databases. After using the tool, the databases were exactly the same but my migration was not working and I started to get odd errors i.e. trying to add tables/ columns that already existed etc. I solved that. I just deleted the migration folder on the local, recreated it, added the initial migration, updated the database and then matched the data of this migration file (local) to the one on the host (delete all the data in the migration file on the host, and add the same data that is on the local into the host). A more detailed explanation is at:
migration synch developmental and production databases
I'm having lots of trouble trying to figure out how to rebuild my database.
I've deleted a table, then i ran this command update-Database -Verbose and it doesn't rebuild my database.
The same thing goes for when i have a table, then i change a column name inside my Model (C#) and then i want to rebuild my database so that the name shows up in the database, and nothing happens when i run the same command.
How can i rebuild my database? I'm sure there's a command or something, besides the update-Database -Verbose.
I'm using Visual Studio express 2012 for Web.
EDIT: Couldn't find a command able to rebuild my Database, though i did find a simple way to do what i wanted.
You can delete tables or rename columns, in your Models, and it will always rebuild your database. In the Solution explorer, you'll find an icon that says "Show All Files", press it and open the folder App_Data, there you'll see your database file, delete it and re-run your application, and it will build again the Database, with all the changes you've made to your Models in your code. So that part about changing catalog and .mdf names in the Web.config file is not needed.
Update-Database is part of the Entity Framework Migrations package, which allows you to script the changes to the database sequentially. The command won't do anything on it's own without migrations to process. If you are using Migrations, you need to use the Add-Migration myNewMigration command first, and verify the script that is generated makes sense.
If you are not using Migrations, you can use the much simpler database options such as DropCreateDatabaseIfModelChanges() against your context class.
Another thing you can try is running Update-Database -f to "force" the migration to run even if it's already present in the _MigrationHistory