This is one of those times that it’s actually a good thing to have one of my projects become obsolete: https://github.com/caboteria/rails-bigint-pk
The upgrade implications for this change scare me. As far as I can tell, if you didn’t check in your schema.rb and only use migrations to set up your development database, its you get a divergent install. While this shouldn’t hurt regular development, its still another thing to add to the list when working with legacy rails applications.
Do you have a good reason for not checking in your schema? That seems like a bad practice.
I do, but i’ve inherited enough apps where they didn’t that its something that sticks out.
rake db:schema:dump ?
Rails versions migrations as of 5.x; I’d assume that only migrations that explicitly opt into recent behaviour would get it.
Maybe they’ll be UUIDs in v6.0 :)
You can default to using UUID’s for primary keys in generators if you want. I submitted that patch last year: http://www.mccartie.com/2015/10/20/default-uuid’s-in-rails.html
I think you jest, but there are drawbacks to using UUIDs for everything. There are some solutions to the drawbacks, but it’s not simple and baked-in to most storage engines. So, there’s tradeoffs.
In my career I have only dealt with tables big enough to overflow integers twice. When that happens it’s a fairly large PITA. This suggests to me that BIGINT may be a sensible default.
Hard to tell if you’re trolling or serious.