Add AI name/description validation to product editor
This commit is contained in:
@@ -1,38 +0,0 @@
|
||||
-- Migration: Map existing numeric order statuses to text values
|
||||
-- Run this ONCE on the production PostgreSQL database after deploying the updated orders import.
|
||||
-- This updates ~2.88M rows. On a busy system, consider running during low-traffic hours.
|
||||
-- The WHERE clause ensures idempotency - only rows with numeric statuses are updated.
|
||||
|
||||
UPDATE orders SET status = CASE status
|
||||
WHEN '0' THEN 'created'
|
||||
WHEN '10' THEN 'unfinished'
|
||||
WHEN '15' THEN 'canceled'
|
||||
WHEN '16' THEN 'combined'
|
||||
WHEN '20' THEN 'placed'
|
||||
WHEN '22' THEN 'placed_incomplete'
|
||||
WHEN '30' THEN 'canceled'
|
||||
WHEN '40' THEN 'awaiting_payment'
|
||||
WHEN '50' THEN 'awaiting_products'
|
||||
WHEN '55' THEN 'shipping_later'
|
||||
WHEN '56' THEN 'shipping_together'
|
||||
WHEN '60' THEN 'ready'
|
||||
WHEN '61' THEN 'flagged'
|
||||
WHEN '62' THEN 'fix_before_pick'
|
||||
WHEN '65' THEN 'manual_picking'
|
||||
WHEN '70' THEN 'in_pt'
|
||||
WHEN '80' THEN 'picked'
|
||||
WHEN '90' THEN 'awaiting_shipment'
|
||||
WHEN '91' THEN 'remote_wait'
|
||||
WHEN '92' THEN 'awaiting_pickup'
|
||||
WHEN '93' THEN 'fix_before_ship'
|
||||
WHEN '95' THEN 'shipped_confirmed'
|
||||
WHEN '100' THEN 'shipped'
|
||||
ELSE status
|
||||
END
|
||||
WHERE status ~ '^\d+$'; -- Only update rows that still have numeric statuses
|
||||
|
||||
-- Verify the migration
|
||||
SELECT status, COUNT(*) as count
|
||||
FROM orders
|
||||
GROUP BY status
|
||||
ORDER BY count DESC;
|
||||
@@ -1,51 +0,0 @@
|
||||
-- Migration 002: Fix discount double-counting in orders
|
||||
--
|
||||
-- PROBLEM: The orders import was calculating discount as:
|
||||
-- discount = (prod_price_reg - prod_price) * quantity <-- "sale savings" (WRONG)
|
||||
-- + prorated points discount
|
||||
-- + item-level promo discounts
|
||||
--
|
||||
-- Since `price` in the orders table already IS the sale price (prod_price, not prod_price_reg),
|
||||
-- the "sale savings" component double-counted the markdown. This resulted in inflated discounts
|
||||
-- and near-zero net_revenue for products sold on sale.
|
||||
--
|
||||
-- Example: Product with regular_price=$30, sale_price=$15, qty=2
|
||||
-- BEFORE (buggy): discount = ($30-$15)*2 + 0 + 0 = $30.00
|
||||
-- net_revenue = $15*2 - $30 = $0.00 (WRONG!)
|
||||
-- AFTER (fixed): discount = 0 + 0 + 0 = $0.00
|
||||
-- net_revenue = $15*2 - $0 = $30.00 (CORRECT!)
|
||||
--
|
||||
-- FIX: This cannot be fixed with a pure SQL migration because PostgreSQL doesn't store
|
||||
-- prod_price_reg. The discount column has the inflated value baked in, and we can't
|
||||
-- decompose which portion was the base_discount vs actual promo discounts.
|
||||
--
|
||||
-- REQUIRED ACTION: Run a FULL (non-incremental) orders re-import after deploying the
|
||||
-- fixed orders.js. This will recalculate all discounts using the corrected formula.
|
||||
--
|
||||
-- Steps:
|
||||
-- 1. Deploy updated orders.js (base_discount removed from discount calculation)
|
||||
-- 2. Run: node scripts/import/orders.js --full
|
||||
-- (or trigger a full sync through whatever mechanism is used)
|
||||
-- 3. After re-import, run the daily snapshots rebuild to propagate corrected revenue:
|
||||
-- psql -f scripts/metrics-new/backfill/rebuild_daily_snapshots.sql
|
||||
-- 4. Re-run metrics calculation:
|
||||
-- node scripts/metrics-new/calculate-metrics-new.js
|
||||
--
|
||||
-- VERIFICATION: After re-import, check the previously-affected products:
|
||||
SELECT
|
||||
o.pid,
|
||||
p.title,
|
||||
o.order_number,
|
||||
o.price,
|
||||
o.quantity,
|
||||
o.discount,
|
||||
(o.price * o.quantity) as gross_revenue,
|
||||
(o.price * o.quantity - o.discount) as net_revenue
|
||||
FROM orders o
|
||||
JOIN products p ON o.pid = p.pid
|
||||
WHERE o.pid IN (624756, 614513)
|
||||
ORDER BY o.date DESC
|
||||
LIMIT 10;
|
||||
|
||||
-- Expected: discount should be 0 (or small promo amount) for regular sales,
|
||||
-- and net_revenue should be close to gross_revenue.
|
||||
Reference in New Issue
Block a user