I have a Postgre SQL database in Heroku. I've had some problems. I needed to delete some local migration files and create brand new schema migration files (which worked) that had all migrations included.
A relationship from this new schema migration file already existed in my Heroku database and when I try to migrate I get this error:
django.db.utils.DatabaseError: relation "quizzer_speaker" already exists
How can I make Heroku actually do the migration? Or how can I make it go to a previous version where that relation didn't exist, so I can just migrate without problems?
Related
I want to delete 2 models from a postgreSQL production database that are no longer used but have data on them.
I am a bit afraid of removing them from the schema and running prisma migrate dev and then having issues with the migration generated in production.
Therefore, my idea was to clean the database before:
1 make a query to the prod database to remove all the data from the tables related.
2 remove the models from the schema locally and run the migration.
3 push the migration to prod with the DB tables empty
What do you guys think?
Should I do that or just don't be afraid and delete the models locally + run prisma migrate dev and then push the migration to prod?
Are there any other ways to accomplish what I want?
Thanks in advance!
The approach you listed looks good.
Another alternative would be to delete the models from schema file and run npx prisma migrate dev command with the --create-only flag to just create the migration file without applying it to the database.
You can inspect the migration file first and if it looks good to you then you can invoke npx prisma migrate dev again to apply it.
Your plan seems a good one! This will ensure that the migration will not be affected by any data that is still present in the tables.
Another option you could consider is to rename the tables in the database, rather than removing them entirely. This will allow you to retrieve the data later (if necessary), but it will also allow you to remove the models from your schema without any issues.
So I would do this:
Rename the tables
Remove the models from the schema locally
push the migration to prod
Remove the renamed tables from step 1.
I would like to know how to update an existing database from another database in mongodb ... but previously a little of context.
I've created an app with strapi and mongodb ( more precisely with mongo atlas) and I'm using 2 environments, development and production(with a development and production database). At the beginning, i've created the development database and i copied/cloned this database to another database with this command (previously I created the db file with mongodump)
mongorestore --uri="mongodb+srv://<username>:<password>#<cluster-url>" --archive="app-development.db" --nsFrom='app-development.*' --nsTo='app-production.*
After creating this database i carried on with my develop into the development database, and now i would like to import the development database into the production database...but i got the error continuing through error: E11000 duplicate key error collection
So I don't know how can i re-import the databases, and also i would like to know if this way is a good practice or i should do it in a different way
I'm getting this error when I'm trying to migrate on an Azure SQL Server db. This project also has a local mysql database and relationships between the two DB's but that doesn't seem to be at issue here
I've tried deleting and squashing the migrations. I've tried --fake-initial. I have realized, though, that the issue is just that django isn't preventing itself from trying to create the table if it already exists during the migration.
I'm curious if there's a setting to prevent django from just sending a create command during the migration if the table already exists.
For now since I'm just developing I can just nuke the DB and start over, but this isn't going to work if I modify a column and try to migrate it in production
Anyone run into this?
I have a SQL Server CE database on my 'live' host that I deployed a few weeks ago. It has a migration history of two old migrations. Then I have my dev database, that has gone through umpteen migrations, and several delete and recreate moments.
Now I would like to use EF migrations to build a migration that will update the production db to match my code-first model on dev. I thought that if I cleared the prod migration history, and ran Add-Migration, EF would compare database and model, and generate a migration class to bring the db up to date with the model.
What really happens is that the migration that gets generated tries to create the whole dd, well, all tables, FKs, and Indexes. How do I get a proper update only, using EF migrations?
If you still have the deployed migration on your Dev box, you can create a script that will bring the deployed version up to date:
Update-Database -Script -SourceMigration: VersionDeployed -TargetMigration: CurrentMigration
You could also try bringing the PROD database down with the migration history (don't clear it). EF should compare the model in the last migration to the current model based on code.
http://cpratt.co/migrating-production-database-with-entity-framework-code-first/#at_pco=smlwn-1.0&at_si=54ad5c7b61c48943&at_ab=per-12&at_pos=0&at_tot=1
I'm working on a project that uses EF6 with code-first migrations.
All the work till now was done on a Dev. environment, including the DB migrations.
I need to deploy the code to another environment (QA), however I've stumbled into a problem:
The DB exists, however there are no tables (I've created the DB manually).
Currently, the code in QA throws Invalid object name 'dbo.__MigrationHistory'. and truly this table doesn't exist in QA, it only exists in DEV where migrations were first enabled.
What is the best practice to work with migrations in multiple development environments (DEV => QA => STG => PROD)?
What is my best course of action?
UPDATE:
I've created the dbo.__MigrationHistory and the schema manually and populated the migrations table from the DEV table. The question still stands since I'll have to deploy to STG and PROD later this month.
If you utilize some kind of continuous integration, you could proceed as follows:
create build configurations in your migrations project that will transform
connection strings to fit environments' requirements (with XDT) on build,
build the project using MSBuild using respective configuration parameter,
use migrate.exe (e.g. from EF Nuget package's folder) to run migrations using the built DLL.
If you don't do CI, then you can just follow the first step and always deploy with your migrations project built with respective build configuration.
Notice: to mess up with __MigrationHistory table manually is never good practice.
To create database you can use CreateDatabaseIfNotExists initializer.
There are a few options you can try:
1- use database initializers:
Database.SetInitializer<UserDbContext>(new MigrateDatabaseToLatestVersion<UserDbContext, Configuration>());
2- use ssdt to migrate tables and data between environments (qa, dev, prod, etc)