在 Laravel 中安全地重命名 Controller、其模型及其迁移

Question

我想重命名 Laravel 中的控制器、其模型及其迁移。

我可以手动完成，但问题是我会花费大量时间（尤其是重命名迁移文件的名称、迁移文件中的内容以及 Laravel 跟踪迁移的表“迁移”） ）。

我现在就可以做到，因为我的迁移次数很少。到目前为止，该应用程序很小（我只是为了开始使用而创建它Laravel）；我只有一个仪表板、一个用户控制器和一个文章控制器（允许用户创建和编辑他们的文章，并允许访客仅查看文章）。但是，如果这种情况再次发生并且我有 30 次迁移怎么办？我可能会不小心弄乱一切并导致错误。

我可以自动重命名控制器吗？如果是，我该怎么做？如果没有，手动重命名控制器时有什么需要特别注意的吗？所以改名后不会出现问题。

注意：我是 Laravel 和 StackOverflow 的新手，所以如果我的问题看起来很愚蠢，我很抱歉；只是别对我无礼。

Answer 1

简短的回答：不要重命名您的迁移。相反，添加table rename迁移。

长答案：

迁移是按时间顺序对数据库所做的更改的列表。它们之所以被命名是migrations因为它们往往会导致数据的大规模移动：数据从一种结构迁移到另一种结构。重命名表就是此类迁移之一。

迁移的好处之一是能够回滚数据库更改。假设您的源代码处于版本控制（git、svn 等）之下，并且某个版本在启动后出现错误，您可以简单地运行“向下迁移”并在修复时恢复应用程序的先前（工作）版本。

为了使上述方案发挥作用，保持迁移文件完整非常重要。理想情况下，您永远不要更改迁移：相反，您可以添加一个新的迁移，其中包含您想要更改的任何内容。

最后举一个例子，如果您最初命名为 model Foo，那么您的迁移将归结为

create_foo migration:
up: create table foo
down: delete table foo

一段时间后，您发现您不小心命名了它，Foo而不是Bar重命名它。您可以添加一些内容，归结为：

rename_foo_to_bar migration:
up: rename table foo to bar
down: rename table bar to foo

但后来发现Bar显然应该是Baz：

rename_bar_to_baz migration:
up: rename table bar to baz
down: rename table baz to bar

...但事实证明该版本有一个错误，因此您恢复代码并运行向下迁移

修复错误后，您可能需要应用错误修复迁移：

fix_some_bug migration
up: rename column or something
down: restore the bug

当发布错误修复时，数据库仍处于rename_foo_to_bar，因此在部署期间， 和rename_bar_to_baz都会fix_some_bug被应用。

通过使用此系统，您可以使数据库与正在运行的代码的当前版本保持同步。

但是，不要轻易使用向下迁移，这通常存在丢失数据的风险。