对于Rails应用程序，如何查找哪些字符串字段具有“旧”255默认字符限制，因为Rails更改了默认限制并将其从schema.rb中删除

如何解决对于Rails应用程序，如何查找哪些字符串字段具有“旧”255默认字符限制，因为Rails更改了默认限制并将其从schema.rb中删除

在Rails / Postgres数据库中如何找到哪些字符串字段仍然具有旧的默认255个字符限制最大大小，因为随着时间的推移，Rails不仅引入了不一致的默认字符串大小，而且还引入了还从schema.rb文件中删除了该信息吗？

我们需要知道需要迁移到:string,limit: nil的哪些“旧”字符串字段以匹配“较新的” string字段。

问题是，在应用程序使用Rails 4.2时创建了一些“新”表和字段，但是使用较早版本的Rails创建了许多“旧”表和字段。

不幸的是，Rails不仅停止了将默认字符串限制放入schema.rb文件中，而且Rails 也将字符串的限制从255更改为 >更大的价值。

最终结果是生产数据库中的某些“旧” string字段可容纳255个字符，而其他“新” string字段则可以容纳当前的默认值（我认为约为1GB） ... 但是schema.rb文件不再指示哪个。

因此，重新创建一个新数据库，然后通过rake db:schema:load（例如，在测试环境中）加载架构，将产生与通过迁移而发展的生产数据库相比显着不同的Test数据库。这导致测试规范通过，尽管由于“测试”和“生产”数据库中完全相同的string字段的大小不一致，导致相同的代码在生产中可能会失败。

作为一个简单的示例，将string字段从表A复制到表B可能会在测试和生产中工作，而将 same 字段从表B复制到表B的另一个方向如果表A是使用255个字符限制字段创建的“旧”表，而表B具有更大的字符串最大值，则A可以在测试中工作，但在生产中失败。

解决方法

类似的事情可能会发生：

ActiveRecord::Base.descendants.reject(&:abstract_class?).each do |klass|
  klass.columns_hash.each do |column,options|
    next unless options.sql_type_metadata.type == :string # might have to modify this
    
    # ... some logic here to look at options.sql_type_metadata.sql_type or options.sql_type_metadata.limit  
  end
end 

您要查找的是位于ModelName.columns_hash方法内的sql_type_metadata上。