Subversion Repositories SmartDukaan

Rev

Rev 37578 | Details | Compare with Previous | Last modification | View Log | RSS feed

Rev Author Line No. Line
37578 amit 1
-- One web offer per model: the badge is keyed on its consolidated CONTENT, not on a
2
-- circular row.
3
--
4
-- Before: one web_offer per circular row, so a model appeared in as many badges as the
5
-- circular had rows naming it - Edge 60 Pro 12+256 carried five. A partner's product card
6
-- listed all five and had to reconcile them.
7
--
8
-- After: every model's offers are consolidated into one description, and models whose
9
-- consolidated terms are IDENTICAL share a single web_offer. Sep'26: 191 badges -> 107,
10
-- covering the same 314 models, each appearing exactly once.
11
--
12
-- circular_page_no / circular_row_no stay for reference but no longer identify a badge -
13
-- one badge now spans many rows. They are left NULL for content-keyed rows, and MySQL
14
-- permits repeated NULLs in uk_circular_row, so the old key does not fight the new one.
15
 
16
ALTER TABLE dtr.web_offer
17
  -- sha256 over the normalised content: modes, values, banks, timing, schemes, tenures,
18
  -- windows. Two models with the same terms hash the same and share the badge.
19
  ADD COLUMN circular_offer_key CHAR(64) NULL,
20
  ADD UNIQUE KEY uk_circular_offer_key (circular_document_id, circular_offer_key);
21
 
37581 amit 22
-- ⚠️ NO DELETE. The old row-keyed badges are retired by the SYNC itself, which
23
-- deactivates any CIRCULAR row with a NULL circular_offer_key on its next run. That is
24
-- strictly better than deleting them here:
37578 amit 25
--
37581 amit 26
--   * nothing is destroyed, so a bad sync is one UPDATE away from being undone
27
--   * web_offer_product has NO foreign key to web_offer, so a DELETE here would have to
28
--     clear its rows separately or strand them as orphans
29
--   * there is no window where a circular has no badges at all - the old ones stay live
30
--     until the new ones exist
37578 amit 31
--
37581 amit 32
-- So this migration is purely additive and safe to run ahead of the deploy.
33
--
34
-- To retire them by hand instead (not needed, but this is the statement):
35
--   UPDATE dtr.web_offer SET active = 0
36
--    WHERE source = 'CIRCULAR' AND circular_offer_key IS NULL;