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 <[email protected]> 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 [email protected]. > To post to this group, send email to [email protected]. > 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/sequel-talk. For more options, visit https://groups.google.com/d/optout.
