I'm really glad to see foreign key support has made its way into Rails migrations, but very quickly ran into an issue with it when working in teams using structure.sql.
Previously, we'd been using the foreigner gem, which generated FK names based on the table and column. This meant the name was consistent every time you ran the migration. With the version that made it into 4.2, part of the FK name is random <https://github.com/senny/rails/commit/8768305f20d12c40241396092a63e0d56269fefe#diff-a0775e1ec64264dc76a8ee71a5211ae3R697>. This means every dev who runs the migration locally generates a different version of structure.sql, leading to conflicts in version control. Right now we're working round this by explicitly setting the FK name in our migrations. I'd like to find a way of fixing this in Rails itself though. My understanding was the reason for switching away from the old format was that the name is arbitrary, and can fall out of date on column renames. By itself I'm not totally convinced that's enough reason to get rid of the more descriptive names (though I agree it's debatable). The restriction on the length of the name (63 characters in Postgres, for example) is a more compelling reason for me. Either way, I'd like to contribute a patch to make migrations generate consistent FK names. I'm happy to implement either of the following (or something else if anyone's got a better ideas): * Switch back to generating human-readable names, accept that people with long table/column names will occasionally have to set them manually * Generate that human-readable name, hash it, and append a substring of the hash to "fk_rails_". This would give you a name which is both short and consistent. Would really appreciate feedback on those approaches. Cheers, Chris -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout.
