Improve migrations support

It is possible auto-generate migrations when model change?

Or … can migrations auto-learn schema differences?

I don’t know if that’s so easy. PHP types can’t be translated cleanly to SQL field definitions. A string, for example, could hold a VARCHAR(45), VARCHAR(70), VARBINARY(255), TEXT or LONGTEXT.

Btw: I think we had that discussion already. Can’t find the thread right now …

If type is the problem, we can fix it specifing type of an attribute in the model. like …

public function types () {

    return array(

        'id' => array(

            'type' => 'pk',


        'name' => array(

            'type' => 'varchar',

            'size' => '255',

            'nullable' => 'true',


        'address' => array(

            'type' => 'relation',

            'relation_type' => 'belongs_to',

            'model' => '{{relations}}',




Or something like that.

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.

I would prefer if it would be the other way around as I always start with migrations first, and then modify the model(s).

It would be nice if the migration could adjust the involved models without my intervention…

‘Nice’ as in not really needed. ;)

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.

I proposed this some time ago

@sensorario: Have a look at my DumpSchemaCommand, but it just can create complete schema and data dumps, at least with foreign keys.

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. ;)

That’s already possible. You can specify “VARCHAR(70) NOT NULL” as field type. Obviously your migrations will no longer be db-agnostic, but it works ;)

I know, and the it isn’t db-agnostic, so it doesn’t really count IMO. :)

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.

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.

If i could define mi model:

public function types () {

    return array(

        'id' => array(

            'type' => 'pk',


        'name' => array(

            'type' => 'string',

            'size' => '777',

            'nullable' => 'true',




I can traslate model to db and db to model. I think is great!!! I can auto-generate migrations.

A client of mine has started a job without migrations. He has a lot of tables. I need to create schema with migration now. But I cant.

Maybe with DumpSchemaCommand I’ll can. Thank you @schmunk

It’s still not totally clear to me in what way this differs from writing a set of migrations…

You can do the above with migrations.

Perhaps you want to do this directly in the model instead of in a migration?

Why can’t you just create the migrations?

What’s stopping you?

It would be handy to let Yii use the model(s), but what about when you add/change/remove fields?

How do you deal with that?

That’s where migrations shine.

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:

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: 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.

I don’t know…

I think it’s great that modules/extensions/packages/whatever can have their own migrations…

However, it would be much more useful if migrations could happen recursively.

The modules/extensions/packages/whatever could register with the MigrationManager so that it knows what to apply when the migrate command is run.

Chained migrations?

With dependencies checking?

Whatever it is, it would then be possible to just run yiic migrate and it will happen.