1. 8
  1.  

  2. 3

    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

    1. 2

      ??

    2. 1

      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.

      1. 1

        Do you have a good reason for not checking in your schema? That seems like a bad practice.

        1. 1

          I do, but i’ve inherited enough apps where they didn’t that its something that sticks out.

          1. 1

            rake db:schema:dump ?

        2. 1

          Rails versions migrations as of 5.x; I’d assume that only migrations that explicitly opt into recent behaviour would get it.

          1. 2

            That’s correct.

        3. 0

          Maybe they’ll be UUIDs in v6.0 :)

          1. 2

            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

            1. 1

              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.