On Friday, March 9, 2018 at 6:45:26 AM UTC-8, Chris Hanks wrote: > > This will change the effects of old migrations, right? A migration that I > wrote a year ago using `primary_key` that formerly created a `serial` > column will now create an identity column. When I write a new migration to > convert my serial primary keys to identity ones (because they do seem like > an improvement) then that migration will work against my existing database > but break if I run all my migrations in sequence on a newer version of > Sequel? So the recommendation in this release will be to go back through > all my old migrations and replace the `primary_key :id` calls with `serial > :id, primary_key: true`? >
It does change the behavior slightly, but only slightly. Both serial and identity end up creating the same sequence, it's just associated to the column better in the identity case. You don't necessarily need to create a migration that converts serial to identity. And if you do so, it's probably not too difficult to write it in such a way that doesn't break if the column is already identity. The example code given in the blog post I linked does raise an exception if the column is already identity, but I think that should be fairly easy to modify so that it just does nothing in that case. Do think it would be worthwhile to add a Database method that converts from serial to identity and doesn't fail if the column is already identity? The recommendation in the release will definitely not be to go through old migrations and modify them. In most cases people using Sequel can probably ignore the difference between identity and serial. > I wouldn't expect a breaking change like this before 6.0.0. What if > instead, primary_key takes a `:type`-esque argument whose value can be > `:identity` or `:serial` to opt into the new/old behavior, and then when > Sequel 6 is released the recommendation is to change old migrations to use > `type: :serial`, and you can (optionally) remove the `type: :identity` from > newer ones? That should maintain backwards compatibility until 6, and also > make the transition pretty straightforward. > You can already force what you want on a per call basis using :serial=>true, :identity=>false. Can you explain what specifically you think will break, ideally with example code? I'm really looking for behavior that works with serial and will break with identity. As far as I know, they operate the same way outside of some corner cases. The corner cases I'm aware of are small enough I think the benefit of defaulting to identity is worth the cost of switching. But I realize I may not be considering some cases, and that's why I requested feedback. Note that in regards to old migrations, breaking compatibility in 6.0.0 would basically have the same effect as breaking it now, it just pushes the problem down the road. Migrations aren't generally like application code in that you are expected to update them on major version bumps. Also, no matter when we make the change, since it only affects PostgreSQL 10.2+, it doesn't just depend on a Sequel version upgrade, but also on when PostgreSQL was upgraded. So unless we never switch from serial to identity, we will always have the issue. Thanks, Jeremy -- You received this message because you are subscribed to the Google Groups "sequel-talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to sequel-talk+unsubscr...@googlegroups.com. To post to this group, send email to sequel-talk@googlegroups.com. Visit this group at https://groups.google.com/group/sequel-talk. For more options, visit https://groups.google.com/d/optout.
