时间戳

首页 > 解决方案 > 在开发的早期阶段是否有替代迁移工作流程。拉拉维尔

laravel - 在开发的早期阶段是否有替代迁移工作流程。拉拉维尔

问题描述

我的推理，不感兴趣的可以跳到下面

我了解迁移的一般过程是如何工作的以及它们所服务的目的，并且很高兴以预期的方式使用它们，即在整个应用程序生命周期中添加和删除字段作为必要的字段。

我的疑问是，在项目开始时，我很少知道给定表中需要的许多字段，在项目的早期阶段，我想设置主要功能和关系，也许只是在客户下定决心之前使用一些无用的字段。

底线是它伤害了我的强迫症，因为我知道那里有额外的迁移文件可能看起来不像项目的 v1.0 ......一旦我达到 v0.5，我可能会决定我已经足够远，可以开始正确管理迁移。

这就是我的想法，但这里有一个问题：

在项目的早期阶段一次又一次地重复使用相同的迁移脚本最干净的步骤是什么，而不必担心数据丢失或回滚。

除此之外，我不想刷新整个迁移，因为我真的更愿意保留我正在玩的任何数据，尤其是用于保持登录到后端等的用户表。

这样做会不会错：

我可以只删除表中的迁移行，然后运行迁移吗？

这感觉就像它会产生副作用，并且可能会导致回滚，是这样吗？迁移表起什么作用，因为这似乎在实践中起作用？

最后的话

请记住，这只是我试图理解的一个概念。如果这是绝对不好的做法，无论如何我都可以接受！

标签： laraveldatabase-migration

解决方案

编辑：

创建一个新的播种机php artisan make:seeder UserSeeder

编辑播种机以“播种”必要的数据。前任：

DB::table('users')->insert([
    'name' => 'John Doe',
    'email' => 'johndoe@example.com',
    'password' => Hash::make('password'),
]);

然后调用内置的 artisan 函数php artisan migrate:fresh --seed，该函数将删除所有表并重新运行所有迁移，然后使用播种机播种数据。

您可以在此处阅读有关此过程的更多信息。

原来的：

如果您计划从长远来看支持实时应用程序，那么您很可能会有很多这些单独的迁移文件，每次制作新的迁移文件时仍然会伤害您的强迫症。每次我创建一个新的迁移来更改表时都会发生这种情况，哈哈。

但是，在开发过程中，如果您正在使用私有代码库并且没有其他开发人员会试图跟上您的更改，我可以理解您的观点。如果你这样做了，你对旧迁移文件所做的任何更改都很难让他们模仿，因为迁移表会跟踪需要运行的迁移（如果有的话），所以如果其他人在你之后尝试迁移改变了以前的迁移，什么都不会发生。

我要做的是在 Laravel 中设置一个数据库播种器，以便在回滚迁移时快速重新播种表中的数据，或者获取表的 sql 转储并在再次迁移后重新插入。

您可以考虑的另一件事是，在开发的这个阶段不要担心迁移目录，一旦您准备好部署或推送，请检查您的表更改并将它们“重构”到您想要的迁移中。但一定要在此之后进行一些彻底的测试，以确保您不会遗漏任何列或更改。

推荐阅读