Our clients do not have admin access to our web servers and we run MVC , how can i clone an existing DB to fork the data without shutting down the current DB ?. At the moment EF creates the new DB but all the records need to be manually created so we wanted to do a fork.
I suppose i could go through all entities in all tables , detach them all and insert into the DB but is there a nicer way ? As writing that code for 100 tables is not quick even if we use reflection .
The other option of doing a backup and restore is a bit painful as some of the DBs are hosted on SQL server and some as attached files .
Ben
EF is not tool for this. Either use native SQL tools like backup / restore or if there is any additional logic needed create SSIS package or custom ADO.NET application for data migration. With EF it will not only take long to do that but it will be also terrible bad and slow solution.
Related
I have a PostgreSQL db that is used by a Nest.Js / Prisma app.
We changed the name of a field in the Prisma schema and added a new field.
Now, when we want to update the PostreSQL structure, I'm running, as suggested by Prisma, the following commands:
npx prisma generate
and then
npx prisma migrate dev --name textSettings-added --create-only
The idea is to use the --create-only flag to review the migration before it is actually made.
However, when I run it I get a list of the changes to be made to the DB and the following message:
We need to reset the PostgreSQL database "my_database" at "my_db_name#cluster.us-east-1.rds.amazonaws.com:5432".
Do you want to continue? All data will be lost.
Of course I choose not to continue, because I don't want to lose the data. Upon inspection I see that the migration file actually contains DROP TABLE for the tables that I simply wanted to modify. How to avoid that?
So how do I run the update without affecting the data?
UPDATE:
I saw that running with --create-only creates a migration which can then be implemented on the DB level using prisma migrate dev, however, in that migration file there are still some commands that drop my previous tables because of some new parameters inside. How can I run prisma migration without deleting my PostgreSQL data?
UPDATE 2:
I don't want Prisma to drop my tables when I just updated them. The migration file generated, however, drops them and then alters them. Do you know what's the best procedure to avoid this drop? I saw somewhere I could first manually update the DB with the new options and then run the migration, so Prisma can find a way to update it, but that seems too manual to me... Maybe some other ideas?
For some cases like renaming tables or columns, Prisma's generated migration files need to be updated if they already contain data.
If that applies to your use case, Prisma's docs suggest to:
Make updates to the prisma schema
Create migration file without applying it (--create-only flag)
Update the migration script to remove the drops and instead write your custom query (e.g. RENAME <table_name> TO <new_name>)
Save and apply the migration (npx prisma migrate dev)
Note that those changes can lead to downtime (renaming a field or model), for which they have outlined the expand and contract pattern.
It might be a Prisma bug: https://github.com/prisma/prisma/issues/8053
I also recently had this situation. It probably should not try to run migration if you only want to create migration file.
But overall it is expected with Prisma to recreate your db sometimes. If you migration is breaking then it will be required to reset the data anyway when you apply it.
I suggest you to create some seeding script so you could consistently re-create the database state, it's very useful for your development environment.
More info
I started using prisma especially for handling database migrations. It handles that well. But there are many open issues for things that it does not handle well related to queries (biggest are related to queryRaw not always working as expected and with no straight forward way to use postgreSQL Row Level Security). Everything I've found to be a problem related to queries in prsima can easily be done in node-postgres.
I realize from the docs that some of these issues are not a problem in knexjs but prisma has a more feature rich migration setup (automatic and can be customized).
Can I safely use prisma and node-postgres together? If so, how? For example use prisma for schema design and database migrations and use node-postgres for all my query logic?
Yes, you can safely use prisma and node-postgres together.
Your workflow will look like the following:
Create a Prisma Schema to define your models and underlying database tables.
Use the Prisma CLI (the prisma npm library) to run migrations to your database. This will generate the client in node_modules/.prisma/client directory, which you could optionally delete as you won't be using it.
Instead of using generated Prisma Client inside your node application, use the node-postgres library to run queries against the database in your application.
Since you're only using Prisma to make any kind of migration or changes to the database structure, there's no risk of your prisma schema not being synced with your database. On the off chance this does happen, you can always get it back in sync using prisma db pull.
Furthermore, since your application is not going to use Prisma client to connect to the database for running queries, node-postgres will handle the connection pool.
I am trying to dump the schema and data from an existing Oracle DB and import it into another Oracle DB.
I have tried using the "Export Wizard" provided by sqldeveloper.
I found answers using Oracle Data Pump, however i do not have access to the filesystem of the DB server.
I expect to get a file that i can copy and import into another DB
Without Data Pump, you have to make some concessions.
The biggest concession is you're going to ask a Client application, running somewhere on your network, to deal with a potentially HUGE amount of data/IO.
Withing reasonable limits, you can use the Tools > Database Export wizard to build a series of SQLPlus style scripts, both DDL (CREATEs) and DATA (INSERTs).
Once you have those scripts, you can use SQLPlus, SQLcl, or SQL Developer to run them on your new/target database.
I've been looking all around the web and i couldnt found a concrete solution to my issue, i want to create a model Client that has an existing table clients in the PostgreSQL server.
Im using rails 4, and i've been trying to create the model Client and the controller Clients like this:
class ClientsController < ApplicationController
scaffold:client
end
But when calling localhost:3000/clients/new a warning of pending migrations appear. It has no sense making the migration if the database and table are already there with information, how can i do to notice rails that the migrations have to be ignored?
UPDATE:
I have generated a model and a controller in rails 4,Client and ClientsController, and configure the database.yml with the postgres adapater and the database name, and i want that rails get the table attributes from the clients table and generate the forms and all the scaffolding CRUD operations. I've seen in the web some similar solutions but with mysql database and i think with rails 3...
Any help is welcome
Did you run a generator to create the model and controller? If so, did it also create a migration file for you under db/migrate?
Delete the migration file and Rails should stop complaining about pending migrations.
If you have other migrations that are pending, run rake db:migrate to run them.
I started off my project by using Entity Framework Code First. When I was ready I uploaded my database and code to my host provider. Everything worked.
I need to add a new field to one of my classes and I don't want to loose the data in the database. Thus, I tried following some blog posts about using Code First Migrations. I did the following:
I backed up my remote (production) database.
I attached this database locally
I added the property to my class
PM> Enable-Migrations
PM> Add-Migration AddSortOrderToCar
PM> Update-Database
At this point I created a .bak file of the local database and then used that file to 'restore' to the remote one.
Lastly, I published the code to the remote site.
When I visit the site I get the following error message:
The model backing the 'blahblah' context has changed since the database was created. Consider using Code First Migrations to update the database.
What am I doing wrong?
From my experience that suggests that migration table is out of sync (even if your data isn't), and that's been part of the db schema now (since 4.3 I think - under system tables).
There could be many reasons and ways to experience that error , but most of the time...
The problematic part is some combination of manually backing/restoring the full database with code changes alongside - I'm not entirely certain as to why always.
In short, even if Db-s are the same migration table data might not be - and hash comparison may fail (still full restore sounds like good enough - but you have 'two sides').
What works for me is to use
Update-Database -Script
That creates a script with a 'migration difference',
which you can manually apply as an SQL script on the target server database (and you should get the right migration table rows inserted etc.).
If that still doesn't work - you can still do two things...
Remove the migration table (target - under system tables) - as per http://blogs.msdn.com/b/adonet/archive/2012/02/09/ef-4-3-automatic-migrations-walkthrough.aspx comments in there - that should fail back to previous behavior and if you're certain that your Db-s are the same - it's just going to 'trust you',
As a last resort I used - make a Update-Database -Script of the full schema (e.g. by initializing an empty db which should force a 'full script'),
find the INSERT INTO [__MigrationHistory] records,
just run those, insert them into the database,
and make sure that your databases - and code match,
that should make things run in sync again.
(disclaimer: this is not a bullet proof to work at all times, you may need to try a few things given your local scenarios - but should get you in sync)
I think in step 6 you need to run Update-Database -Verbose
Also this link is very helpful for updating database in EF with Scaffolding
http://www.asp.net/mvc/overview/older-versions/hands-on-labs/aspnet-mvc-4-entity-framework-scaffolding-and-migrations