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
Related
I am new to mvc in asp.net, so I have started with movie application in mvc with code first approach. My problem is when I change or add new field in movie class, then I got an error like
The model backing the 'MovieDBContext' context has changed since the database was created. Consider using Code First Migrations to update the database (http://go.microsoft.com/fwlink/?LinkId=238269).
So anyone knows the solution for it with code first approach after changing or add any new field ...
using three command its solve which are list below.....which we have to write in package manager console
1)Enable-Migrations -ContextTypeName MvcMovie.Models.MovieDBContext
2)add-migration Initial
3)update-database
but why this error occurs and is there any other solution for it without the above three commands in mvc 4?
You have changed the Code First models since applying them to your database, so you need to reupdate, to apply these changes. First you add a new migration. Do this by typying this into the package manager console:
add-migration migrationName
migrationName should be unique and descriptive of the changes. After running this command, you should have a migration file, which you can apply by running:
update-database
Given that the changes are valid, they should now be applied to your database.
You have to do this every time you make changes to your CF models.
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
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
i ran
./symfony doctrine:build --all --and-load --no-confirmation
with the example's schema.yml file and all the tables and model classes in symfony populated nicely. however when i changed that schema.yml file completely by deleting all the example tables and rewrote my own, the database didn't delete the old changes nor did it delete any of the model classes. it just added the new tables into the database.
how can i get doctrine to "forget" about the old schema.yml ?
You need to run doctrine:clean-model-files to delete model classes that are not represented in project or plugin schema.yml files.
.. the old data was stored in an example file under the same directory, project_root/config/doctrine/schema_example.yml
turns out doctrine imports every file, not just schema.yml. woops.
I have a bunch of rails models that I'm re-writing into a single model to simplify my code and reduce unnecessary tables.
I'm wondering what the best way to delete a model class and its table is. I want past migrations to still succeed, but I don't want to leave the empty models lying around.
Do I have to manually delete the old migrations that reference these models, then manually delete the class files?
Does anyone have any tips for the best way to do this?
All in one solution.
Run the following commands:
rails destroy model ModelName
rails g migration DropTableModelName
The former will generate a new migration file which should looks like this:
class DropTableModelName < ActiveRecord::Migration
def change
drop_table :model_name
end
end
Now run db:migrate and you're done.
If you'd like to completely get rid of of a model and its table do this:
rails destroy model Name
The question is a bit stale now, but I just did:
rails destroy scaffold <ModelName> -p
The -p flag shows "pretend" output, which is good for seeing what will happen. Remove the '-p' flag and the results will match the output. This cleaned the entire collection of M-V-C files + testing + js files + the original migration, no problem.
I guess if you are one who likes to hand edit your migrations and include multiple steps in each, losing the original migration could break db:setup, so buyer beware. Keeping one action == one migration file should avoid this potential snafu.
What about doing ruby script/destroy model? That should take care of the model and the migration.
Depending on how far into development or production you are, you may want to migrate the models out safely using a migration to remove/backup data or what not. Then as bobbywilson0 suggested, using
script/destroy model
or if you rspec anything
script/destroy rspec_model
This will remove any spec tests as well.
Or you can always just drag them to the trash folder.
You can take a look at this one at rails guide.
But I suggest, if it is possible, you should delete the models and all references to the models. This will probably save time later as you don't need to maintain the dead code in the codebase.
If you'd rather have a manual based answer:
First run the following command to identify which migrations you want removed:
rake db:migrate:status
Feel free to grep -i on it too if you're confident of your naming scheme.
Make note of all the "add x to model name" and similar alterations to your Model. These can be removed using:
rails d migration AddXToModelName
Do this for every migration besides the initial create migration. The following command will take care of the initial create migration and the files associated with the model:
rails d model ModelName