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).
Related
Scenario
We want to autofill a table with new static content with doctrine, ideally with something like a fixture class or similar.
We follow the simple development life-cycle with development to staging to production. And we are using Doctrine v2.6 with Symfony v3.4. Every release step is executed by an Jenkins job.
For development and staging we use the very useful and simple doctrine-fixtures-bundle to auto-fill our database with test-datasets. The database-schema is auto-generated by doctrine:schema:update on basis of our entities.
I've tried to use the fixtures also for production but even with doctrine:fixtures:load --fixtures=src/MyBundle/DataFixture/ORM/MyFixture.php it is purging the whole database. Then I read something about the --append command to prevent doctrine from purging the database. But then it will append the datasets in every release process (?). Nevertheless, it also feels like a very bad practice.
What I'm wondering
Is it possible to truncate the table, load table records with static data loaded from a class that can be executed via a command line? Or is there a completely different (and clean) way for such a case? Is the doctrine:migration bundle the real way to go?
Thanks for your help!
You should create a Command for populate tables.
https://symfony.com/doc/current/console.html
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.
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
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.
(Make this CW if needed)
We are two developers working on a web application based (PHP5, ZF, Doctrine, MySQL5). We are working each with a local webserver and a local database. The database schema is defined in a YAML file.
What's the best way to keep our database schemas in sync?
Here's how we do it: Whenever developer "A" makes a change, he generates a migration class. Then he commits the migration file developer "B" executes the migration class.
But creating a migration class on every db change is a rather tedious process.
Do you have a better solution?
I don't know how you do in the Zend Framework with Doctrine. Here's how I would do it in Symfony with Propel. Though the exact procedure may vary, but the underlying concept is the same.
I have unit tests on my DAL.
Whenever the schema changes, we check in the yml and the generated ORM code ( You do have a source control, don't you). I set the check-in to auto-mode, meaning I will get all the check-in instantly.
If the schema changes don't affect my thing, then I would just ignore the changes. But if the schema changes break my thing, then I will rebuild my form, ORM classes and whatnot by using symfony propel build command. Rebuilding those infrastructures is just a single command line thing, so there is no problem for me.
Finally, after rebuilding, I will run my unit tests, to make sure everything is OK. If not, I better get them fixed!
I see that this question is already answered but Doctrine can migrate your databases for you without having to blow away the whole thing. We use this for every schema change where one developer changes his/her local yaml file, generates new models locally, creates a migration using Doctrine, runs that migration locally to change the db, then checks in both the new yaml file and the migration. Then other developers check out the changed yaml file and migration, then they generate new models and run the migration to sync their db. Deploying the code to our QA and production environments is pretty much the same process.
More information on Doctrine migrations can be found on the Doctrine site.