【问题标题】:Creating migrations in Laravel 4 for an existing DB在 Laravel 4 中为现有数据库创建迁移
【发布时间】:2014-05-03 09:57:07
【问题描述】:

我即将开始为现有应用程序构建一个 API,该数据库已经投入生产。未来功能会慢慢移植到 API 上,应用会变得更加“以 API 为中心”。

其中一个主要出发点是采用迁移和构建过程。我对为现有架构创建迁移而不在执行时中断生产的最佳方式持保留态度。

由于我们希望快速将功能移植到 API,因此理想情况下,我们希望在构建过程中重新创建当前架构并进行一些核心单元测试,而不是仅仅为未来的更改创建迁移.

这就是我不确定最佳起点的地方。

这样的任务最好的方法是什么?

  1. 能否将当前架构作为我们的第一次迁移导入?
  2. 能否将这个初始迁移包含在类似以下的内容中: if ( App::environment() !== 'production' ) 确保它不在生产环境中执行?
  3. 排除特定环境的迁移是否可以,否则会导致问题吗?

是否有另一种方法或一些我想念的愚蠢简单的东西? :)

【问题讨论】:

    标签: php mysql laravel migration


    【解决方案1】:

    我根本不建议在生产环境中运行迁移,但是如果您必须先制作数据库的备份副本并在本地创建数据库的副本并在那里进行迁移,然后进行测试以确保一切顺利工作正常。

    1. 您可以创建第一个迁移并手动将所有架构布局添加到其中。但我实际上会在几次迁移中执行此操作,以使每个表都作为自己的迁移。
    2. 由于迁移是使用 artisan 从 CLI 运行的,因此您可以传递您希望在其上运行迁移的环境和数据库:

      artisan migrate --database="connectionName" --env="local"

    3. 除了我上面所说的生产环境之外,在特定环境中运行迁移没有问题。

    请记住将步骤 1 中的所有现有架构布局(迁移文件名,不包括扩展名,例如 2014_03_25_143340_AddCountriesTable)添加到数据库中的迁移表中,否则在步骤 2 中运行命令将引发有关表已存在的错误。

    希望这会有所帮助。

    【讨论】:

    • 您有什么理由不在生产环境中运行迁移?我考虑在迁移中使用保护的原因是为了防止它在生产中运行 - 以防有人意外“迁移”并删除了所有表。
    • 我更喜欢根据项目手动执行此操作,因为我可以控制更改而不是自动化。但这只是个人喜好。
    【解决方案2】:

    不久前我创建了一个工具,它将为您当前的数据库架构生成所有迁移。它还将新创建的迁移添加到迁移表中,因为这些表已经存在。你可以在这里得到它:https://github.com/Xethron/migrations-generator

    其次,我在我的 DatabaseSeeder 中使用以下代码行,但您可以将其添加到您希望在生产中禁用的任何功能:

    if (App::environment() === 'production') {
        exit('Don\'t be stupid, this is a production server!!!');
    }
    

    如果您通过抛出错误或像我上面所做的那样停止执行,这应该不是问题。如果你不这样做,Laravel 将相信更改成功发生并将它们从迁移表中删除,并在运行迁移时导致错误。唯一的例外是,如果您同时排除 up 和 down 代码(但我不明白您为什么要这样做)

    希望这会有所帮助。

    【讨论】:

      猜你喜欢
      • 2014-06-24
      • 2014-08-03
      • 1970-01-01
      • 1970-01-01
      • 2015-03-04
      • 2017-05-25
      • 2016-05-10
      • 1970-01-01
      • 2019-05-03
      相关资源
      最近更新 更多