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.
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 have recently started using code first and migrations and I'm pretty happy with it.. I have been following the constant pattern of add-migration and update-database!
I have just tried to move from localdb to SQL Express and im having a real pain..
when I try and run the application.. I get the follow error..
Cannot find the object "dbo.AspNetUsers" because it does not exist or you do not have permissions.
In my Global file I have..
Database.SetInitializer(new MigrateDatabaseToLatestVersion());
Any ideas? It looks like the core forms tables are not being created?
if I run my application without the Initializer in the global file I get this.
Migrations is enabled for context 'ApplicationDbContext' but the database does not exist or contains no mapped tables. Use Migrations to create the database and its tables, for example by running the 'Update-Database' command from the Package Manager Console.
Thanks
Ste.
End of long day of testing various scenarios where I don't have to recreate a production database...
We started off with EF, and didn't get wise enough during development to move from automatic migrations to named migrations. Now I'm trying to rewind the clock, and create an initial migration that aligns with the production database.
Is this possible to align a model has with an automatic migration has in the migration table?
Should I just create an empty migration to get started with named migrations? My only problem with this is how to create the DB when a new developer joins... I could simply restore the db, and then apply migrations, but that ruins a beautiful EF migration story!
Delete the production DB, create, and write a script to re-import the data (sounds hacky).
Another wrinkle - the DB was created with EF5, and we are now developing with EF6.
Thanks in advance for your help.
It should be possible:
Delete the __MigrationHistory table
Delete any migrations in your project
Disable automatic migrations in your migrations configuration class
Add-Migration InitialCreate
Update-Database -Script
Execute the portion of the script that creates the __MigrationHistory table and inserts a row into it
Repeat steps 1 & 6 for any other existing databases
I also strongly recommend reading Code First Migrations in Team Environments.
If you don't like step 7 of bricelam's answer. Then keep reading.
Because upgrading from automatic migrations to manual can also be automated. And you don't need to delete the migrationhistory table like bricelam says.
In this case I assume you have one development machine, and multiple other (development) machines where databases already exist.
On your development machine you move your database into a safe location (keeping it safe to test your automatic upgrade procedure). (You might want to make sure your code is in the same exact state as all the database which you want to upgrade).
Delete any migrations in your project (you should't have any yet)
Disable automatic migrations in your migrations configuration class
Add-Migration InitialCreate
Put a backup (copy!) of your database back into place
On startup of your application (or your upgrade app) you do something like:
using (var db = new YourDatabaseContext())
{
InitialCreate.SkipInitialCreate = db.Database.Exists();
}
And in your InitialCreate you add something like:
public static bool SkipInitialCreate = false;
public override void Up()
{
// Skip initial create
if (SkipInitialCreate)
return;
This assumes that if a database exists it has the same structure as the one you had on your dev machine. Of course this could be way more complex than that for you. For more control you could inspect DbMigrator object for your config, and skip more than one migration. (would have been nice if you could query the hash of the model in the DbMigrator...)
After the code in step 4 add something like:
var configuration = new YourDatabaseConfiguration();
var migrator = new DbMigrator(configuration);
migrator.Update();
Start your application on your dev machine to test the upgrade. Your history table should have an automaticmigration record and a initialcreate record.
If everything works out you should be able to simple deploy and run the app on machines where the db already exists.
One very important aspect (and maybe the reason bricelam says you needed to delete the history table) is that if the AutomaticMigration record in that table is newer than one of your manual migrations you are going to have a Bad time. Because the migrator uses the dates to sort out the work it needs to do.
So if there are systems out there still automatically upgrading to the newest auto-upgrade model, then you are in a bit of a pickle.
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.