README

遗憾的是，我们决定不再维护此项目了（查看原因）。如果您想将其他软件包作为此软件包的替代品，请发送电子邮件至 hello@knplabs.com。

迁移

这是一个简单的silex和doctrine的本地 schema迁移系统。

安装

像往常一样，只需在您的 composer.json 中包含 knplabs/migration-service-provider（别告诉我您没有，现在已经2012年了），并注册服务。您将需要传递 migration.path 选项，其中应包含您的迁移文件路径

$app->register(new \Knp\Provider\MigrationServiceProvider(), array(
    'migration.path' => __DIR__.'/../src/Resources/migration'
));

聊太多，我想写迁移！

我现在太懒，不想写完整的文档，所以您将不得不依赖两个外部资源

1. 市场迁移
2. Doctrine DBAL Schema Manager的官方文档

运行迁移

有两种方法可以运行迁移

使用 before 处理器

如果您在注册服务时传递了 migration.register_before_handler（设置为 true），则将为迁移注册一个 before 处理器。这意味着迁移管理器将在您的应用程序每次请求时运行。

您可能希望为开发模式启用此行为，但在生产环境中请不要这样做！

使用 knp:migration:migrate 命令

如果您正确安装了控制台服务提供程序，则可以使用 knp:migration:migrate 命令。

编写迁移

迁移由一个包含迁移类的单个文件组成。按照设计，迁移文件必须命名为类似 <version>_<migration_name>Migration.php 的东西，并位于 src/Resources/migrations 中，类名为 <migration_name>Migration。例如，如果您的迁移将一个 bar 字段添加到 foo 表中，并且是您模式中的第5个迁移，则应将文件命名为 05_FooBarMigration.php，类名应为 FooBarMigration。

除了这些命名约定之外，您的迁移类必须扩展 Knp\Migration\AbstractMigration，它提供了一些辅助方法，例如 getVersion 和迁移方法的默认实现。

迁移方法包括4个方法

• schemaUp
• schemaDown
• appUp
• appDown

名称相当直观。每个schema*方法都接受一个Doctrine\DBAL\Schema\Schema实例，您需要对其操作以添加、删除或修改字段和/或表。而app*方法则接受一个Silex\Application实例，即您的应用程序。您可以在市场的CommentMarkdownCacheMigration中看到一个有用的appUp迁移示例。

迁移信息

您还应该了解最后一个方法：getMigrationInfo。此方法应返回对迁移的描述（虽然是可选的，您可以选择不实现）。当运行实现getMigrationInfo方法的迁移时，如果您使用twig，将在您的twig环境中设置一个全局变量，其中包含所有已运行迁移信息的一个数组。

然后您可以使用类似以下的方式使用它：

      {% if migration_infos is defined %}
        <div class="alert alert-success">
          <p>Some migrations have been run:</p>
          <ul>
          {% for info in migration_infos %}
            <li>{{ info }}</li>
          {% endfor %}
        </div>
      {% endif %}