Production allows edc and delivery payment methods through a payment_methods_type_check changed outside the migrations, and has rows of both. 000094 rewrote the constraint with only cash, card, digital_wallet and point, so it failed on production (in its transaction, leaving the database dirty at 94 with nothing applied). 000094 now keeps edc and delivery, down included, and also allows qr, which the code accepts but no constraint did. 000098 sets the same list where the old 000094 already ran, as on staging. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
8 lines
557 B
SQL
8 lines
557 B
SQL
-- Production also has edc and delivery payment methods, allowed by a constraint changed
|
|
-- outside the migrations, and the code also accepts qr, which no constraint allowed.
|
|
-- 000094 first rewrote the constraint without them, which
|
|
-- failed on production and, where it ran, dropped them. Keep every type in use.
|
|
ALTER TABLE payment_methods DROP CONSTRAINT IF EXISTS payment_methods_type_check;
|
|
ALTER TABLE payment_methods ADD CONSTRAINT payment_methods_type_check
|
|
CHECK (type IN ('cash', 'card', 'digital_wallet', 'qr', 'edc', 'delivery', 'point'));
|