Thanks for the quick reply Jeremy. It's been my policy for a long while to make all migrations reversible. Whether up/down or change, that's the rule in our shop. -JK
On Tuesday, September 21, 2021 at 7:14:32 PM UTC-7 Jeremy Evans wrote: > On Tue, Sep 21, 2021 at 6:31 PM John Knapp <[email protected]> wrote: > >> Hi, >> >> I'm transitioning a table from a three way composite PK to a single >> integer PK thus: >> >> 1. In the up: >> 1. drop_constraint :jcus_requirements_orgs_pkey >> 2. add_primary_key :id >> 2. In the down: >> 1. drop_constraint :jcus_requirements_pkey, type: :primary_key >> 2. add_primary_key [:jcu_id, :requirement_id, :org_id], name: >> :jcus_requirements_orgs_pkey >> >> However, when running the down, the constraint is removed but the column >> remains. (Adding a name: :id didn't help but I doubt you're surprised by >> that.) >> >> I wound up adding a drop_column :id in the down block which left me with >> a reciprocal up / down migration. (I'm picky that way.) >> >> But I remain curious if I've missed a more obvious solution (to remove >> constraint and the named column in a single step) or if this is a bug. So . >> . . I thought I'd ask. :-) >> > > Depending on the database, you could try just the drop_column and see if > it also removes the constraint. However, I think the most portable > approach is the one you already have with both the drop_constraint and the > drop_column. > > Don't fear separate up/down migrations. Over 90% of the migrations in my > production applications use up/down and not change. > > 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 view this discussion on the web visit https://groups.google.com/d/msgid/sequel-talk/393bcb51-e00d-426f-bc61-612c8d130822n%40googlegroups.com.
