Reputation: 20493
I'm a beginner with symfony (1.4 + Doctrine), but there is a point which scares me. It seems that whenever one wants to change a model, the only way is to change the schema for the database (config/doctrine/schema.yml
) and then call symphony doctrine:build
, which flushes all the current data in the database.
This does not seem to me like a sane way to proceed. What if after one year my app is in production I decide that my users need to be able to add their facebook page to the profile? In other frameworks (I'm used to CakePHP) it is just a matter of adding a field in the users
table and modifying a model file and the profile view. In symfony... well, I don't know, that's why I'm asking here. I'm sure I'm missing something, as the symfony designers surely have considered the idea that one may want to refactor an application after the launch. What is the correct way to do this?
Upvotes: 3
Views: 2384
Reputation: 1898
Migrations is the right way to do it. But, if you don't want to use migrations for some reason, another option is to update your schema.yml, then rebuild your models, etc. like this:
symfony doctrine:build-model
symfony doctrine:build-forms
symfony doctrine:build-filters
symfony doctrine:build-sql
When you deploy that code, you'll need to manually update your database with whatever fields you're adding/changing.
Upvotes: 0
Reputation: 96
I never use build-all when there is data in my db. I just use build-classes for the models and build-sql, then I change the db, adding or changing fields by hand.
Upvotes: 0
Reputation: 237845
You need to look into the migrations framework. This is basically made up of creating classes that describe the schema change. You can see a symfony 1.2 tutorial here: http://www.symfony-project.org/doctrine/1_2/en/07-Migrations and much of this will be valid for 1.4 as well.
Upvotes: 2