Well, I thought of the PHP data type. You might end up with a new MEDIUMTEXT field when all you wanted was a VARCHAR(60). Equally it might not be clear if a float field is now a currency or a real float etc.

programmer /ˈprəʊgramə/, noun: a device that converts ►coffee into ►code

No, I need it. I work with others framework and I can create all migrations I need and when I want. Just with a console command. I cannot imagine to develop with a distributed team (with yii) with migrations that I have to make by hand.

If I'll can only start with migrations, yii's migrations are not scalable. jacmoe, I really need this stuff.

If I'll can only start with migrations, yii's migrations are not scalable.

total nonsense, happily using migrations in a distributed team of around 20 devs and it's really not a problem. In fact it's generally quite important to be specific about exactly the kind of fields you're creating, because otherwise you'll end up with performance problems. E.g. how do you automatically add an index? Creating migrations automagically will not solve the one pain point when working with distributed teams, which is when migrations from different developers clash, but this is really just a communications issue (merge more often!)

In fact if you're syncing the db to the model, you don't need migrations at all, some frameworks do this, but it's not a good approach in my opinion, too much black magic.

The benefit of using migrations - like it is now - is that it can be committed to source control.
The database schema is generated by the migrations. And can't be source controlled.
It's just output. Generated.

I don't see the problem.

As Phpnode said, migrations is well suited in a distributed team.

I would like, however, more control about the fields generated by migrations, like the size of the text fields, to improve performance.

Migrations works great for agile development because it encourages iterative development, and that includes the schema.
Before Yii had that, it was a pain in the arse.

E.g. how do you automatically add an index? Creating migrations automagically will not solve the one pain point when working with distributed teams, which is when migrations from different developers clash, but this is really just a communications issue (merge more often!)

Well, work a project developed with a big team (with another framework). We have a phing task called daily. Every day we start our job we run "phing daily". This task update our database. We do not care to know if someone update database. I just run a command every day that keeps the line db. But .. I think this is also possible with yii. The issue is another one.

phpnode, on 02 July 2012 - 04:24 PM, said:

In fact if you're syncing the db to the model, you don't need migrations at all, some frameworks do this, but it's not a good approach in my opinion, too much black magic.

In yii we create first the table, and then model. Good or not, we are not able to do the inverse (from model to db) just because our model is not translatable in a table. Doctrine2 is able to create a two-way relationship between classes and php database. Is not black magic. But imho Doctrine2 is too verbose.

Yea Jacmoe I agree with you here, migrations solve any issues we need for migration. While using models to create automated migrations might sound good in theory, it quickly becomes a useless and complex process. For example this can in no way replace migrations as its often other things need doing only possible in migrations (e.g. data manipulation).

The following issues are created by using models as migrations:

No way can migrations be removed so we now have two things doing the same thing (essentially).

Which to run first, models or migration? a migration might need a model change to be made before it can run or vice versa, adds confusion and potential bugs.

you wouldn't be able to rollback model changes.

when running yiic migrate would you also check models? have to check all models for changes against tables, time and resource intensive (my current project has 50 models).

if you make a separate yiic command for model migrations you add confusion of extra commands.

While there might be solutions for the above, I'm going to quote "if it ain't broke...".

Yii2 should also support multiple migration "scopes", like this extension does: http://www.yiiframew...base-migration/
If you're dealing with modules as extension packages, you don't always want to tie these migrations into your application migrations.

Current Yii supports it but syntax is a bit complex (check my Yeeki module).

Yeah, I know, I am also using it, but I guess it needs some work to get it run smoothly with the package manager.

By the way, it's a bit off-topic, but I just noticed that your Yeeki module is only available as a whole Yii application, would be really nice to have a submodule here: https://github.com/s...pp/modules/wiki to include it into other projects - because I was looking for Yii wiki module
Just my two cents here, because I think migrations, packages, modules, configurations, themes and so on are very closely related to each other.