I have created migration and created the database and the tables . For example the tables are
A B C D E . Now again I have changed some part of code and ran update-database command . Everything went smooth and nice and the tables showed the columns . Now accidentally I manually deleted one two tables D and E. Now when I try to run the migration with update-database . It runs properly but doesn't create the tables which I deleted manually . I tried to delete the existing migration and re-run update-database . It gives the error that apart from the two tables . There already an object existing in 'A ,B, C ' bla bla name.
Any idea how to get rid of this situation without dropping database and recreate the deleted tables using migration ? Cause i dont want to drop the database as it contains the data in rest of the tables. How to proceed in this situation where I have existing tables in database and accidentally I have manually deleted few tables from SQL server from SSMS .
How to recreate the tables again using migration ?
Oh my entity framework version is 6.0.2
EF Migration history is stored in the table _MigrationHistory. Remove the table from the Database. Caution: This will erase all the Migration history and you will have to re-create all the tables
I finally figured out the solution . Its basically change in strategy how we use migration . The Migration Add-migration only checks the Models and the previous migration timestamp cs files possibly . so until and unless we provide update-database command in nuget . it Never actually gets to know which Tables have got deleted manually . So to the context when we try to perform some migration like alter on the tables . It causes problematic migration since that table doesn't exist on the database but the migration assumes it is already there . So for that there is a manual work . Here are the steps after we have deleted a table manually from the database
Check the models existing in entities with correspondence to the database table . If we have found there are some anomaly in the database table which is missing from database but it exists as entity that means. They both are not in sync with each other. So we have to find the model => Table relation for each .
If we have created initial migration with all tables then copy the deleted createTable code from the migration file .
Paste it into the last recently generated migration file. And then generate the script or run the update-database command . That would create the deleted database table . However there is no automatic command which would both sync between all entities and the database tables . That's something which we have to track partially manual in migration.
you can do a simple trick here, remove the specific migration history rows, which affect your deleted tables from
dbo.__EFMigrationsHistory
then run update-database command,
enjoy
IMHO the most straightforward solution is to generate SQL script form the migration and run only a part of the script, that creates missing tables.
Update-Database -Source MigrationBeforeCreatingTables -Target MigrationAfterCreatingTables -Script
not best but possible way:
1)create a new migration, don't update the base
2)find migration that added tables you need
3)copy up and down parts from that old migration
4)past those things in the new migration file
5)update the database by the new migration
Related
I've just reviewed a colleague's work and there is an empty EF migration in his PR (up and down methods contain no code). There is another migration after this with DB modifications.
I believe that this empty migration can be deleted on the basis that it does absolutely nothing. There should be a corresponding entry in the _MigrationHistory table, which can also be deleted safely, in my opinion.
My colleagues believe that it should be left in there "just in case".
Are there any EF experts who can say which approach is best, and why?
Тhe truth is somewhere in the middle. You can delete it, but do not delete the migration file directly.
-> Removing A Migration
The following command removes a migration:
[Command Line]
dotnet ef migrations remove
[Package Manager Console]
remove-migration
You will use this command to remove the latest migration. This will remove the class file that was generated for the latest migration and it will also revert the ModelSnapshot file back to the state of the previous migration. If there are no pending migrations, an exception will be raised. If you want to remove a migration that has been committed, you must reverse the migration first (see below).
You should always use commands to remove a migration instead of simply deleting the migration code file, otherwise the snapshot and migrations will fall out of sync with eachother. Then future migrations will be based on a model that is incorrect. Nevertheless, the remove command will recognise if migration files have been deleted and will revert the snapshot accordingly.
If you need to remove a migration that was generated before the most recent one, you must remove all sunsequent migrations first, then adjust the model and then create a new migration to cater for the changes.
Sores: https://www.learnentityframeworkcore.com/migrations
This is probably really simple/obvious but I am new to this -
I have a database with some tables, let's say tA, tB and tC. In a migration I dropped tC, because at that point I needed to working on a different branch. However, I'm now working on a branch in a project that needs tC to exist.
The migrations for creating all tables are present on this branch.
I don't care if tC is empty. But if I run rake db:create, will it then re-create all tables? Because I do not want to lose the data in the other tables, tA & tB.
TL;DR - How to create a table (which I dropped in an earlier creation) without also recreating (and losing the data of) the tables I did not drop?
How did you drop the table tC? Is it through console/command line? If yes, then to recreate the tC table, you have 2 choices:
Create a new migration file to only create table tC (optimal and easiest fix)
bundle exec rails g migration CreateTableTC
Then add the new migration with this conditional statement:
unless table_exists?(:table_tC)
create_table :table_tC do |t|
........
end
end
Then run this command on your terminal:
bundle exec rake db:migrate
This will create table tC if your database hasn't got one, will not erase data on other tables, and will not be executed if your database has table tC
Use GUI for your database (if you are using postgres, you may use PgAdmin)
Here's what I ended up doing: using the Rails console, I simply ran the migration that created that particular table in the first place again. See this Q&A: Run a single migration file.
After some changes I've made today in my schema.yml, each of one followed by the diff, migrate, build commands, the diff operation stopped working.
The last successful migration was the 243rd.
Now, every new change I make, when I give the diff command, the result is always the same:
/usr/bin/php /.../symfony --color doctrine:generate-migrations-diff
>> doctrine generating migration diff
>> file+ /tmp/doctrine_schema_92228.yml
Done.
No new file is created in lib/migration/doctrine, so I cannot use the migrate command to commit the changes to the db.
I tried to clear the cache, clean model files, build all classes, and also reboot.
Any ideas?
This is the best way I have come across to make migrations and success everytime. Cost me a lot to guess but works perfectly and works with multiple databases. I can be wrong in some sentences so feel free to add or correct me in anything you see.
MIGRATIONS, the safest way :)
If you need to work Migrations for multiple databases apply these patches and clear symfony cache, they work perfectly:
doctrine_core.r7687
doctrine_manager.r7657
A. BACKUP PROJECT AND DATABASE:
Save Symfony project Files. (optional but safe way).
Save Database Table Schemas only.
Save Database Table Data only.
Save Database Table Schema with Data.
B. HOW TO MAKE CHANGES TO .yml FILES:
.yml files cannot contain strange symbols, like ñ, ´, ```... or non UTF characters..
Always shows spaces and tabs in Notepad++ or Sublime. There cannot be tabs!!
You CANT have two modules with the same name, even in different databases. Never set two modules with same name or you will have a lot of problems.
If you want to work with multiple databases, you must specify the connection attribute at the beginning of your schema.yml file:
connection: doctrine_master
Working with multiple databases, again you must set the binding connection for the module with the right connection:
Tbtest001:
connection: doctrine_master
tableName: tb_test001
Setting the right variable value and type in schema.yml:
Schema Files
Variables, models and types
Working with multiple databases, take care and modify only one schema.yml for only one database each time!
If you are adding a new table with relations to another table, its recommended to do it in two steps, two migrations. First only add the table and migrate. Then Add the relation and Migrate again. It is the saftest way.
You can have different schemas.yml in different places.
C. MIGRATING THE CHANGES:
Install this plugin, because it has fixes and improvements for checking changes:
idlDoctrineMigrationPlugin
Make a new table for each database for your project. Needed for the plugin to work:
name: migration_version , column: version (int (11)). (autoincrement=false).
In version column, set its value to the lastest migration version you have now. You must do this step for every database where you have the table migration_version:
UPDATE databasetest.migration_version SET databasetest.migration_version.version='31';
UPDATE databasetest2.migration_version SET databasetest2.migration_version.version='31';
Clear Symfony cache:
symfony cc
Make the migration difference (you need the plugin above and version tables created)
symfony model:diff > migratediff.log
Check if the lastest generated changes are right in the following files:
.\lib\migration\doctrine\XXXXXX_versionXXX.php
.\data\migration\history\XXXXXXXXXX.yml
Proceed with the migration UP by specifing a number!, NEVER make migrate UP!. Also take in mind the new parameter --connection. It works now if you applied the above patches and it will migrate only the right databases:
symfony doctrine:migrate 32 --connection=doctrine_master > migrateUP.log
Rebuild models, Forms, Filters, Delete old models..
symfony doctrine:build-model
symfony doctrine:build-forms
symfony doctrine:build-filters
symfony doctrine:clean-model-files
symfony cc
Set all databases to the lastest migration number in their table migration_version:
UPDATE databasetest.migration_version SET databasetest.migration_version.version='32';
UPDATE databasetest2.migration_version SET databasetest2.migration_version.version='32';
Optional step, if you want to know the lastest SQL query send to the database after the migration:
symfony doctrine:build-sql [--application[="..."]] [--env="..."]
D. LINKS AND FILES:
Correct way to do a migrations diff
Doctrine migrations fallback
http://trac.symfony-project.org/ticket/7272
http://trac.symfony-project.org/ticket/7689
http://trac.symfony-project.org/ticket/8604
http://php-opensource-help.blogspot.com/2010/07/how-to-get-connection-from-doctrine-to.html
http://www.doctrine-project.org/documentation/manual/1_1/en/connections
http://forum.symfony-project.org/viewtopic.php?t=29361&p=104098
Main Files involved in migrations:
Migration.php, Builder.php, sfTaskMigration.php
If I have two migration files:
20110414132423_insert_bulk_data.rb #1st
20111122105951_add_some_columns.rb #2nd
and I run rake db:migrate, is the 1st one run firstly since it has older timestamp??
Since I am in the middle of someone else's code, he made the 20110414132423_insert_bulk_data migration which insert data to table, but this migration file complains an unknown column in the table, then I found the missing column is defined in the 2nd 20111122105951_add_some_columns.rb migration file which has newer timestamp...
How can I get rid of this?
Shortly, yes. The timestamp is used to order migrations and to navigate between them. See more here
delete this migrations
generate two new migrations in the way you need to run
I use symfony 1.4.11 , I have a project...
I have schema.yml , and I have migrations with tables which are not in the schema. For example I have in my db "pages" table, and it not described in schema. When I get project in first time I make: build --all --and-load --no-confirmation ; and I get my db,I think that it created some tables from Base classes, because there are many tables in my db, but they are not described in schema . So now I need add a few new fields to my page table, I make migration, and it is all ok, I have new fields in my db, but I do not have it in schema.yml, so when I make symfony doctrine:build --all-classes nothing happen it do not generate page class with new column. I do not understand, if it possible to generate new class or changes to class without schema? How people that make project before me , do this?
Thank you! And sorry for my bad English
it's possible. Try to use the following command to clean you model files.
./symfony doctrine:clean-model-files
if you want to use migrations, you should not use doctrine:build --all --and-load --no-confirmation anymore. Migrations assume incremental updates. Dropping and building the DB every time is not good.
Try to follow those resources
http://www.slideshare.net/weaverryan/the-art-of-doctrine-migrations
http://www.slideshare.net/denderello/symfony-live-2010-using-doctrine-migrations