Just a quick follow-up Jeremy to say your hunch on drop_column :id works 
fine. So in the case of my transition from composite pk to a standard id 
column, it works like this:

   1. In the up
      1. drop_constraint :jcus_requirements_orgs_pkey
      2. add_primary_key :id
      2. In the down
      1. drop_column :id (so simple!)
      2. add_primary_key [:jcu_id, :requirement_id, :org_id], name: 
      :jcus_requirements_orgs_pkey
      
(This with pg and sequel_pg gem)
On Wednesday, September 22, 2021 at 6:48:21 AM UTC-7 John Knapp wrote:

> 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/8fceb1e8-5db6-4784-b67d-ca278959afddn%40googlegroups.com.

Reply via email to