Using services/records etc in migrations

Question

The database migrations documentation does say:

Please note that we do not recommend using records directly within a migration

Are there technical reasons for this recommendation, or is it something you'd just rather not support? I don't mind if I'm on my own as far as support goes, but it seems like I might be able to use migrations to deploy schema changes across environments if I was careful?

Of course this would be for private, site-specific plugins, not anything that was going to be publicly released, so I don't think the issue Brandon highlighted here would necessarily apply.

I have successfully created a new tag group using the following:

public function safeUp()
{
    $tagGroup         = new TagGroupModel();
    $tagGroup->name   = Craft::t('Tag Group');
    $tagGroup->handle = 'tagGroup';

    craft()->tags->saveTagGroup($tagGroup);
}

But obviously this is quite a simple example, and a migration that added fields, sections and entry types (like the InstallService does) would be more complicated and should probably check each record was saved properly before continuing with the next bit.

Are all of Craft's services available while a migration is being run?

Answer 1

Are there technical reasons for this recommendation, or is it something you'd just rather not support?

It's more along the lines of it's something you're not going to want to support.

The problem is that things like services and records change over time. Methods get renamed/deleted, attributes change, parameters change, etc.

By using them in a migration you're assuming that the methods you're calling and the attributes you're using are going to be there for the rest of time and that's not necessarily going to be true.

A year from now if someone tries to run that migration, there's a chance those services and records are going to look very different and the migration is going to fail because it was written for what the service/record looked like a year ago.

You're much better off thinking of migrations as little self-contained applications with as few dependencies on external Craft classes as possible.