I've deployed my symfony project to the server and now I wanna change the models inside schema.yml without reseting other unrelated database tables and keep the current data.
Is there any diff / upgrade feature for symfony propel project ?
Take a look at sfPropelSqlDiffPlugin (available from the plugin repository). I've been using it for quite a while and it has worked well for me. It's not perfect (it doesn't deal too well with non-standard stuff like specifying a sqltype in your schema, for example), but it has made life much easier for me.
Instead of trusting the plugin to do the actual execution of the diffed SQL, I prefer to do:
./symfony propel:build-sql-diff
This creates a SQL file in your data dir, which you can then inspect/edit prior to manually executing the script.
You can generate the sql by using the 'propel:build-sql' command. The result is a valid SQL file which you can import yourself.
In our very big project we just keep track of the SQL itself. We build the models and generate the SQL. Then we copy the new generated SQL to a file containing the SQL for our version. Take care of the SQL where tables are changed instead of created, since you must manually alter that table by yourself.
It cannot be done from Symfony afaik.
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).
Is it safe to build a Yii application over a SQL Server database which is being used by another software?
The ideia is to migrate that desktop software for a WebApp but I must let the database structure untouched.
It's a quite complex database and I have very complex SQL Queries as well, so I should avoid DAO and AR. I've been looking for some information around the web but it's not clear to me how safe it will be this process. Should I build all the application with RAW SQL and be careful with it's implementation?
Can anyone of you show me the right path I should follow?
Thanks in advance
It is absolutely safe to do this, with Yii you can use any database structure you need. You'll only need to create your models based on your current database structure.
Here a quick guide to use Yii with SQLServer http://www.yiiframework.com/wiki/192/config-use-ms-sql-server-2005-2008/
You can use just plain SQL with Yii, have a look at http://www.yiiframework.com/doc/api/1.1/CDbCommand
But if you want more flexibility, I can recommend you the following way.
create an initial database migration, just execute() a plain SQL dump from your exisiting database.
create database migrations as you need them
apply migrations
develop
go to step 1. if you want to test with newer data and reapply migrations to your database
shut down old application
As your migrations are versioned with your application, you could eg. maintain a branch with the old db-schema and work parallel on an updated version with another db-schema.
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.
I need to load data from an old DB into a migrated schema of this DB using Doctrine migration system.
I guess Doctrine might help me in this process.
I tried and lost a few hours using ETL scripts programs, without success.
From my point of view I need to :
Create a DB with the V0 schema
Load the data from the old DB (schema are identical)
Migrate DB to latest version using Doctrine migration
Extract data
Load it in the new DB
WHat do you think of this process?
Do you think it is feasable using Doctrine?
I tried a few searches on Google without success.
I am currently reviewed the features of Doctrine_Core class.
Thanks for your help
Yes, it is possible to migrate data from one database to another using Doctrine.
It sounds like you're trying to do a one-time database revision and migration and that your applications are not currently written using Doctrine. In that scenario, database abstraction has little or no benefit, unless you're also rewriting the applications to use it.
If you have no prior experience using Doctrine then I seriously doubt that writing custom migration classes in it will be easier than doing it with whatever database API you are already experienced using. It makes sense to use the migration classes (some times) if you are already using Doctrine for your development. Otherwise it's another layer and API you don't need.
I'm using Doctrine 1.2, which has some nice features for migrations but also a number of bugs and omissions of expected functionality. Reportedly version 2 improves on this but I haven't used it yet.
(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.