During development, I run Doctrine's schema:update command often to sync the database schema to my changing entity definitions. Once I'm ready to commit a feature, I want to roll up all the changes into a migration class which I can commit to git.
The problem is that in order to run migrations:diff I need to roll back the database schema to its state before I started messing with schema:update. Doing schema:drop then migrations:migrate is no good because dropping the schema doesn't drop the migration_versions table. That means I have to go into MySQL and manually drop all databases before running the existing migrations and creating the new one.
It works but it feels like I'm doing it wrong. Any better ideas?
I do not know 100% correct answer to the question, but there was one option. Every time you need to run schema:update --force first dump sql with schema:update --dump-sql and store it. Then, the need to rollback base is not necessary
Related
I'm using database migrations with PHP symfony framework and I noticed that there are a lot of files, and when I build my project and every time many files (migrations) are executed.
What is best practice to manage migrations? Could I delete them and create only one database dump file, for database initiation?
I'm assuming you're using Doctrine Migrations to create these files. On dev you can always regenerate the database using the doctrine:schema:update command.
When setting up a new instance you can also use the doctrine:schema:create command which will also create the latest table definitions for you.
That brings us to your question; do you need to keep all the migrations? As long as you know that the migrations have been executed on outdated instances you can safely archive (my preferred option) or delete them as they will never be called again.
I would prefer to use migrations on production instead of doctrine:schema:update, because you can have some problems while updating process. It is always a better option IMO to keep an eye on what happens with the DB.
On development env you can easily use doctrine:schema:update command but you should use migrations on production. In some cases the command may brake the migrations (it happened to me a few times).
I'm about to start building an API for an existing app with the DB already in production. Functionality will slowly be ported to the API in the future and the app will become more "API-centric".
One of the main starting points is to adopt migrations and a build process. I have reservations on the best way to create migrations for an existing schema without breaking production when they are executed.
As we would like to move quickly with porting functionality over to the API, we ideally want to recreate our current schema as part of our build process and get some core unit tests in place - as opposed to just creating migrations for future changes.
This is where I become unsure as to the best place to start.
What is the best approach for a task like this?
Could the current schema be imported as our first migration?
Could this initial migration be wrapped in something like:
if ( App::environment() !== 'production' ) to ensure it isn't executed in a production environment?
Is it ok to exclude a migration for a particular environment or could this cause problems?
Is there maybe another approach or something stupidly simple I'm missing? :)
I created a tool not to long ago that will generate all the migrations for your current database schema. It also adds the newly created migrations to the migrations table, as the tables already exist. You can get it here: https://github.com/Xethron/migrations-generator
Secondly, I use the following line of code in my DatabaseSeeder, but you can add it to any function you wish to disable in production:
if (App::environment() === 'production') {
exit('Don\'t be stupid, this is a production server!!!');
}
It shouldn't be a problem if you stop execution by throwing an error or as I do above. If you don't, Laravel will believe the changes happened successfully and remove them from the migrations table, and cause errors when running your migrations. The only exception is if you exclude both the up and down code (But I can't see why you would want to do that)
Hope this helps.
I wouldn't suggest running migrations in production environment at all, but if you must then make a backup copy of the database first and also create a copy of the database locally and do the migration there then test to make sure it all works properly.
You could create your first migration and manually add all the schema layout to it. But I would actually do this in a few migrations to have each table as its own migration.
Since migrations are run from the CLI using artisan you can pass the environment and the database you want the migration to be run on:
artisan migrate --database="connectionName" --env="local"
There is no issue running migration on a particular environment besides what I stated above for production.
Remember to add all existing schema layouts from step 1 (the migration file name excluding the extension e.g. 2014_03_25_143340_AddCountriesTable) to the migrations table in the database, otherwise running the command in step 2 will throw errors about table already exist.
Hope this helps.
Here is the legacy documentation explaining what "generate-migrations-db" does:
http://symfony.com/legacy/doc/doctrine/1_2/en/07-Migrations
It says
Generate migration classes from existing database connections
(doctrine-generate-migrations-db, doctrine-gen-migrations-from-db)
Also:
Generating Migrations
Doctrine offers the ability to generate sets of
migration classes for existing databases or existing models as well as
generating blank migration classes for you to fill in with the code to
make your schema changes.
From Database
If you have an existing database you can build a set of migration
classes that will re-create your database by running the following
command.
$ ./symfony doctrine:generate-migrations-db
In other words: it takes the schema from the database and generates a migration that performs that schema creation. No entities, no classes, no mappings are used in this process. It just takes a DB and builds a migration class.
We do not have generate-migrations-db anymore. Do we have something that performs that task? I couldn't find. If it was replaced by some other command, please let me know. If it was just removed, please let know.
I'm not aware of a command in Doctrine or the Migrations Bundle that creates migration files for an existing database.
So here's how I did it instead:
Install DoctrineMigrationsBundle
Create a new blank database
Update your config or parameters to point to this blank database rather than to your "real" one
Run php app/console doctrine:migrations:diff. This will create a migrations file that creates your database tables etc from scratch
Change back your config/parameters
Hope this is helpful.
Take a look at the DoctrineMigrationsBundle, which can generate migration classes with sql statements for migration.
I am building a complex application but i want to know that is it safe to use doctrine migrations in production.
For eg. the site has been used for 1 year and company wants to add extra attribute to user table.
So do i straight way chnage by going in database or through doctrine migrations
This is one of the intended uses (and benefits) of migrations - to automate the changes to your database quickly and accurately. Yes, they can and in most cases should be used to update your database in production.
Edit: The Symfony2 documentation also explains clearly this is one of the purposes of migrations.
Of course, the end goal of writing migrations is to be able to use them to reliably update your database structure when you deploy your application. By running the migrations locally (or on a beta server), you can ensure that the migrations work as you expect.
...
Yes it would be safe.
I would just add an extra attribute in the User entity. Then run the doctrine:generate:entities command. That should generate the get/set methods. Then just update your database using doctrine:schema:update --force. That should add it into your database table.
Doctrine (on Ubuntu): What command generate models from database without delete existing models?(I add new tables soo i want update models)
Thanks
If you're using Doctrine 1, you'll need to make use of Migrations. Migrations can either be written manually, or auto-generated one of a few different commands:
./doctrine generate-migration
./doctrine generate-migrations-db
./doctrine generate-migrations-models
Migrations can be a fairly complex topic, so I would read up on the documentation. You may also want to check out this slide show.
If you're using Doctrine 2, things get a little simpler. It doesn't have a Migrations class (yet), but there an easy-to-use command to non-destructively update your db schema:
./doctrine orm:schema-tool:update
This has worked well for me, but can sometimes fail due to complex foreign key constraints.