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

<p>It's more along the lines of it's something <em>you're</em> not going to want to support.</p>

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

<p>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.</p>

<p>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.</p>

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

CC BY-SA 3.0
2015-02-27T16:14:40.437Z
Ah yeah, that makes perfect sense. I suppose everything can be done with SQL queries anyway, just like the old days. I'll be extra careful!
Mike Pepper
CC BY-SA 3.0
2015-02-27T15:53:37.200Z
2015-02-27T15:53:37.200Z
Brad Bell
<p>The <a href="http://buildwithcraft.com/docs/plugins/migrations" rel="nofollow noreferrer">database migrations documentation</a> does say:</p>

<blockquote>
  <p>Please note that we do <strong>not</strong> recommend using records directly within a migration</p>
</blockquote>

<p>Are there <em>technical reasons</em> 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?</p>

<p>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 <a href="https://craftcms.stackexchange.com/a/4861/157">here</a> would necessarily apply.</p>

<p>I have successfully created a new tag group using the following:</p>

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

    craft()-&gt;tags-&gt;saveTagGroup($tagGroup);
}
</code></pre>

<p>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.</p>

<p>Are all of Craft's services available while a migration is being run? </p>

<plugin-development><migration><services>
Using services/records etc in migrations
# Using services/records etc in migrations

(Asked by: username_0 on 2015-02-27)

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?

**Tags:** plugin-development, migration, services

---

## 1 answers

### Answer by username_1 on 2015-02-27. Score: 2 | Accepted answer

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

> **Comments:**
> **username_0**: Ah yeah, that makes perfect sense. I suppose everything can be done with SQL queries anyway, just like the old days. I'll be extra careful!  

---

