I am looking forward to identity fields. The serial column permission thing
bit me once. Not a huge deal to work around but it will be nice not to
worry a about it.

On Tue, Mar 13, 2018 at 7:41 AM, Jeremy Evans <jeremyeva...@gmail.com>
wrote:

> On Monday, March 12, 2018 at 11:20:43 AM UTC-7, Chris Hanks wrote:
>>
>> Sorry, I wasn't getting reply notifications. I'm not sure offhand what
>> code a dev might write that would break against an identity column but not
>> a serial one (maybe some DDL that renames a table and then also tries to
>> rename its auto-generated sequence? I know I've done that before). Maybe
>> I'm being overly cautious, but having any meaningful change in the
>> generated DDL for old migrations feels dangerous, whether it happens
>> because the Sequel version upgraded or the Postgres version did.
>>
>
> I can certainly understand that.  I'm in general very cautious about
> making changes in this area.  However, because this change would always be
> dependent on both the Sequel and PostgreSQL versions, there would always be
> a risk of mixed versions.
>
> Basically, the only way to 100% ensure no changes would be to keep using
> serial instead of identity forever, and then most users would not
> automatically take advantages to the improvements that identity offers over
> serial.
>
> I just tested the renaming of tables and in both the identity and serial
> cases, the sequence name does not get renamed automatically, and the SQL to
> rename the sequence manually is the same for both identity and serial.
>
> The database method you mention might help migrations. I'm not a huge fan
>> of ActiveRecord in general, but they now have migrations declare what AR
>> version they were written against, which helps when making changes to the
>> migration API like this.
>>
>
> I've thought about doing this since ActiveRecord introduced the approach,
> but I'm not convinced it's a net benefit.  For one, Sequel doesn't really
> have a migration API like ActiveRecord.  Most of what people think of as
> the migration API are really Database methods, the migrations are just a
> way to call the Database methods in a way that works with the migrators.
> So in Sequel this would basically involve changing a setting on the
> Database object, running the migration, then changing the setting back.
> Anyway, I won't completely rule out adding it to Sequel in the future, but
> I'm not sold yet.
>
> Certainly in this particular case it wouldn't help, since the decision on
> whether to use identity depends on the PostgreSQL version and not just the
> Sequel version.
>
> 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.
>

-- 
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