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.

Reply via email to