Doctrine迁移是否可用于生产应用程序？

Question

正如前面所讨论的,我们正在开发周围需要有它的数据库相当频繁升级和跨数据库的方式,我们通过发展阶段移动Zend框架的PHP应用程序.

我们目前正在使用Rails迁移,尽管它们使用Ruby(而且Windows上的Ruby就是它的混乱),我们很难将迁移分发给具有基于Windows的安装的客户.即使在Linux上,使用Ruby访问MS SQL和Oracle数据库也很痛苦.

我们想用Doctrine替换Rails迁移,但他们觉得非常不成熟.没有太多文档,跟踪器中有一些错误会引发关于项目状态的危险信号,例如:

• renameColumn()删除列
• 表重命名时数据丢失

查看代码,这两个实际上删除了原始表或列,并在不保留数据的情况下重新创建它.这是一个彻底的交易破坏者,让我觉得没有人真正使用Doctrine Migrations.

另外,我在文档中读到迁移使用顺序编号(版本1,版本2等)使它们完全不适合分支开发,但DoctrineMigrationsBundle Symfony文档使用了基于日期的版本,这些版本确实有意义.

有没有人有这个工具的真实世界经验,或者知道它的发展状况？

Answer 1

我们更多地了解了Doctrine Migrations,并对其内部工作有了一些了解(并更新了OP中链接的错误).

主要问题是Doctrine在迁移方面有着根本不同的方法.它从您的数据库模式构建一个抽象模型,然后允许您修改该模型.这些修改对底层数据库没有影响,但Doctrine使用它们来推断必须在数据库上进行的实际更改.

这就像是数据库的差异.这有一些非常讨厌的后果.例如,如果重命名DB上的列,则模型上的操作如下所示:

public function renameColumn($oldColumnName, $newColumnName)
{
    $column = $this->getColumn($oldColumnName);
    $this->dropColumn($oldColumnName);

    $column->_setName($newColumnName);
    return $this;
}

如果您使用此功能,然后让Doctrine应用迁移,那么它将查看旧模式和新模式之间的差异(缺少列,添加的列及其类型)并推断是否需要重命名现有列或者删除旧的并创建一个新的.这意味着Doctrine认为重命名一个列实际上与删除它并再次创建它相同,因此对它非常愚蠢.

• 如果重命名单个列而不更改其他任何内容,它将在DBMS上发出"重命名"命令.
• 如果重命名列并将其类型(例如,varchar(80)更改为varchar(100)),它将删除它并再次创建它.
• 如果你重命名2列而不改变任何东西,它会惊慌失措并丢弃它们并重新创建它们(diff算法就是那么简单)

我认为这是一种糟糕的数据库迁移方法,因为它无法可靠地运行.这种工具的重点在于跨迁移保持数据,这就失败了这个基本要求.

这就是说,无论如何我们正在使用它,因为没有更好的东西.我们在不可靠的操作中添加了故意的失败消息,以避免让开发人员陷入许多陷阱.

Answer 2

说实话,Doctrine迁移比大多数产品更好; 但是,它们有点不成熟,很难找到文档.话虽如此,如果保持在有限的范围内,他们的工作就好了.

此外,使用任何迁移工具,您只需要小心,不要指望它提供魔法.

话虽这么说,但是没有一个跨平台工具可以像liquibase一样充满功能.此外,我所知道的其他工具都没有包含数据库文档工具.

关于liquibase的以下讨论应该为您提供足够的信息来帮助您入门:

http://slidedecks.wilmoore.com/2012-confoo/painless-version-controlled-database-refactoring