我有几个非常简短的问题，它们都是相关的，我认为不需要为每个问题单独发帖
如何对表单前端发生的验证重新排序？现在 :username 的验证消息在底部，但它是表单上的第一个字段，所以它们应该在顶部。这是在我向设计 gem 添加字段之后，所以我猜测设计验证在我之前运行。
是否不赞成编辑设计 gem 的 db 迁移文件，或者我应该为我想要进行的每个更改进行 rails g 迁移？我的应用尚未投入生产，但我刚刚看到一些教程，每个人都推荐此步骤。
【问题讨论】：
标签： ruby-on-rails ruby ruby-on-rails-3 devise
(1) 索引将用于从用户表中查找行，因此如果您将通过电子邮件查找用户，那么您可以为电子邮件和用户名添加索引。否则只有用户名就可以了。
(3) 是的，不赞成编辑已经运行的迁移文件，因为跟踪更改变得很困难，并且您最终可能会遇到无法仅回滚您编辑的部分的情况。因此，当您需要更改数据库时，您应该创建一个新的迁移。但是，由于您的应用程序尚未投入生产，根据您拥有的数据量，这样做可能不会有太大的危害。您的来电。
【讨论】：
第 1 点：这取决于您想要做到的严格程度和方式。一方面，由于在两个字段上添加唯一约束/索引非常便宜和容易（我假设是传统的 SQL 模式），你为什么不呢？另一方面，一些 Rails 纯粹主义者认为（有充分理由）您应该放弃任何数据库供应商的细节并在 rails 模型中强制执行所有约束，然后添加索引（而不是约束）作为性能优化。我是老派，所以我更喜欢前者，但我也是一个纯粹主义者，所以我确保我的 rails 模型是正确的，并且我的应用程序从不依赖于 db 供应商的细节。
在 2 上：我将处理视图层中的验证错误显示，即不要挂断它们的运行顺序 - 将所有验证视为原子操作。然后，在视图中，不只是按照错误消息发生的顺序转储错误消息，而是重新排序散列，甚至显式地测试和输出每个键。它的可维护性稍差，因为如果添加新输入，则需要更新该视图代码。但是，与试图维护验证运行顺序的头痛相比，这微不足道。就个人而言，我不相信错误消息的打印顺序是相关的，但我知道这会以错误的方式惹恼一些人。
第 3 点：同意 Sebi，不要编辑 gem 或 gem 提供的任何东西，也不要追溯编辑迁移。添加一个新的迁移是微不足道的，所以只要去做，然后继续做有趣的事情。如果我是一个非生产应用程序的唯一程序员，我会走捷径，但只要它上线或有其他开发人员，我就会更加自律。而且，我花在 Rails 编程上的时间越多，我发现编写 rails db 迁移与 SQL 一样容易，甚至更容易。
【讨论】：