我想分享一些信息，我们在利用STI的表编写主动记录迁移时发现有趣的信息（单表继承）。我们遇到了一个不那么明显的Gotcha，STI模型在迁移课程中重新定义，并希望在解决随后的问题的同时探索我们的思考过程。

我们要更新一列（满足_requirements.）基于键入子模型中的某些条件业务逻辑的STI表中。我们现有的导出模型中的继承关系由他们导出的实体类型决定（例如ProductExport.那DigitalAssetExport.， 等等。）。我们对最低要求的定义已更改，我们希望更新我们所有的产品出口，以确保它们被正确标记。请注意，已简化以下示例以说明一个点，并不旨在举例说明实现以下类型的迁移的最佳方法：

到目前为止，它看起来好像通过重新定义我们尝试使用的任何模型进行迁移最佳实践，执行单个原子事务等。然而，当运行此迁移时，它会失败！错误消息读取：

怎么会这样？方法遇见_all_requirements？定义在ProductExport.模型。但是，您可能会注意到错误消息正在告诉我们正在发生的事情。我们的迁移正在使用一个实例运行ProductExport.， 不是MarkProductExportSwhichMeetAllRequiress :: ProductExport.。嗯，这很奇怪。努力快速解决我们尝试将所有逻辑推入的问题出口模型并使用Where子句来获取ProductExports.：

再一次，我们迎接了Nomethoderror.例外。唔。经过一点头划伤，我们意识到Rails正在使用它是STI Magic来实例化ProductExport.，悄悄挫败我们尝试使用我们的重新定义模型。解决方案很简单，我们需要明确地告诉Rails忽略继承列并实例化我们重新定义的实例出口模型。

voilà！就像那样，迁移成功，每个人都很开心。一个简单的变化，起初可能看起来不明显，但一旦你想到它，就会有很多意义。如果我们参考现有方法，这种类型的GOTCHA可能会滑过裂缝。ProductExport.我们将最终结束了具有外部模型依赖的迁移。我们认为我们会分享这些信息，以帮助您在STI模型执行自己的迁移时避免遇到类似的问题。

感谢您通过主动记录迁移的旅程。我们很乐意听到您在执行类似任务时遇到的任何故事/解决方案。