Difference between revisions of "VbzCart/pieces/catalog/building"

from HTYP, the free directory anyone can edit if they can prove to me that they're not a spambot
< VbzCart‎ | pieces‎ | catalog
Jump to navigation Jump to search
(removed src_* table defs; forgot that I had done them here, and went and created the ctg_* bunch instead -- the cost of frequent interruption)
m (updated template name)
 
(42 intermediate revisions by the same user not shown)
Line 1: Line 1:
==Navigation==
 
[[VbzCart]]: [[VbzCart catalog building|catalog building]]
 
 
==Version==
 
==Version==
This is being revised yet again for the 2007 VbzCart-MySQL migration project; the previous version is here: [[vbzwiki:VbzCart catalog building 2006|VbzCart catalog building 2006]].
+
This is a tricky process which has been revised multiple times.
==Process==
 
This is only a draft, as the process is still being worked out. Right now this process does not "recycle" junked records in cat_items; perhaps that was a bad idea to begin with, or perhaps some other use can be found for junked records that isn't part of catalog-building. There probably should be some process which removes junked records from use so they aren't taking up space and CPU cycles.
 
# Update the list of all catalog-based items ([calc Items Updates saved])
 
#* [[#(Step 1) qryVb_Items_updates_append]] -- Add any new items to [calc Items Updates saved]
 
#** [[#(Step 1a) qryVb_Items_updates_new]] -- in-print items that are new
 
#*** [[#(Step 1aa) qryVb_Items_updates]] -- all the items currently available from suppliers (in print)
 
#** [[#(Step 1b) qryVb_Items_updates_copy_fields]]
 
# For all items in [calc Items Updates saved] where ID_Item IS NULL, create new records in cat_items and update the corresponding records in [calc Items Updates saved]
 
#* [[#(Step 2) qryVb_Items_results_append]] -- adds new cat_items rows for any calculated items not already cross-referenced. It doesn't cross-reference them, however. That is done by the next query.
 
#** [[#(Step 2a) qryVb_Items_results]]
 
# Fill in any blank ID_Item fields in [calc Items Updates saved] records:
 
#* [[#(Step 3) qryVb_Items_updates_index_new]] -- plugs the Item ID back into the calculated temp table. It assumes (1) 1:1 correspondence between Item IDs and catalog numbers, and (2) catalog numbers won't be changed during the course of a build (though they can change in general).
 
# Copy calculated item data over to [cat_items]:
 
#* [[#(Step 4) qryVb_Items_results_update]]
 
# Final flag updates:
 
#* [[#(Step 5) qryVb_Items_update_final]]
 
#** Clear isInPrint flag for cat_items not found in calculated in-print listing
 
#** Set isForSale for cat_items with stock for sale
 
#** Update stock quantities for all cat_items
 
# Housekeeping: mark table as updated so cached tables get recalculated
 
#* [[#(Step 6) qryVb_Items_mark_updated]]
 
  
==SQL - queries==
+
* {{l/sub|2017}} version - 2016 code apparently never really got finished, and the Items table needs some flag changes
These are from the MS Access 97 version, gradually being honed down for migration to MySQL
+
* {{l/sub|2016}} version - webified version of 2010, with rules finally documented
===(Step 1a) qryVb_Items_updates_new===
+
* '''2010''' version: see {{l/vbzcart/code|maint/build-cat.php}}
<sql>SELECT c.*
+
* {{l/sub|2009}} version - SQL statements executed directly from PHP code
FROM qryCtg_Items_updates_joinable AS c LEFT JOIN ctg_updates AS s
+
* {{l/sub|2008}} version - started in 2007 - a set of stored queries called from a stored procedure
ON c.IDS_Item=s.IDS_Item
+
* {{l/sub|2006}} version
WHERE s.IDS_Item IS NULL;</sql>
 
  
===(Step 1) qryVb_Items_updates_append===
+
It's interesting to note that I originally thought of SCM Groups as groups ''of Titles'' -- an explanation from the [[VbzCart/tables]] page on 2008-02-17 (and only removed on 2016-02-01) says:
<sql>INSERT INTO ctg_updates (
+
<blockquote>The key concept here is "catalog title groups" (CTGs). A CTG is a set of titles which are all available with the same set of options (e.g. sizes) at the same prices (e.g. $10 S, $11 M-XL, $12 2XL). The final vbz catalog (cat_items) is the result of a sort of vector multiplication of Titles (cat_titles) and CTGs plus any items in stock.
  ID_Item,
+
</blockquote>
  IDS_Item,
+
This conceptualization no longer works, as a SCM Title may have one or more SCM Groups -- e.g. if it has a set of standard sizes (like S-3X) but is also available in super-large sizes (4X+).
  CatNum,
 
  CatSfx,
 
  ID_Title,
 
  ID_CTG_Group,
 
  ID_CTG_Title,
 
  ID_CTG_Item,
 
  ID_ItTyp,
 
  ID_ItOpt )
 
SELECT
 
  0 AS ID_Item,
 
  IDS_Item,
 
  CatNum,
 
  CatSfx,
 
  ID_Title,
 
  ID_TGroup,
 
  ID_TGTitle,
 
  ID_TGItem,
 
  ID_ItTyp,
 
  ID_ItOpt
 
FROM qryVb_Items_Updates_new;
 
</sql>
 
===(Step 2) qryVb_Items_results_append===
 
This adds new cat_items rows for any calculated items not already cross-referenced. It doesn't cross-reference them, however. That is done by the next query.
 
<sql>INSERT INTO cat_items (
 
  CatNum,
 
  isForSale,
 
  isMaster,
 
  isInPrint,
 
  isCloseOut,
 
  ID_ItTyp,
 
  ID_ItOpt,
 
  ItOpt_Descr,
 
  ItOpt_Sort,
 
  ID_ShipCost,
 
  PriceBuy,
 
  PriceSell,
 
  PriceList )
 
SELECT
 
  r.CatNum,
 
  r.isForSale,
 
  FALSE AS isMaster,
 
  r.isInPrint,
 
  r.isCloseOut,
 
  r.ID_ItTyp,
 
  r.ID_ItOpt,
 
  r.ItOpt_Descr,
 
  r.ItOpt_Sort,
 
  r.ID_ShipCost,
 
  r.PriceBuy,
 
  r.PriceSell,
 
  r.PriceList
 
FROM qryCtg_Items_updates AS r LEFT JOIN cat_items AS i ON r.ID_Item=i.ID
 
WHERE i.ID IS NULL;
 
</sql>
 
 
 
===(Step 3) qryVb_Items_updates_index_new===
 
This plugs the Item ID back into the calculated temp table. It assumes (1) 1:1 correspondence between Item IDs and catalog numbers, and (2) catalog numbers won't be changed during the course of a build (though they can change in general).
 
<sql>UPDATE
 
  ctg_updates AS s LEFT JOIN
 
  cat_items AS i
 
ON i.CatNum=s.CatNum
 
SET
 
  s.ID_Item = i.ID,
 
  isForSale = FALSE,
 
  isInPrint = FALSE
 
WHERE
 
  s.ID_Item IS NULL;
 
</sql>
 
 
 
===(Step 4) qryVb_Items_results_update===
 
<sql>UPDATE
 
  qryCtg_build AS r LEFT JOIN
 
  cat_items AS i
 
ON
 
  r.ID_Item=i.ID
 
SET
 
  i.CatNum = r.CatNum,
 
  i.isForSale = r.isForSale,
 
  i.isInPrint = r.isInPrint,
 
  i.isCloseOut = r.isCloseOut,
 
  i.isPulled = FALSE,
 
  i.isDumped = FALSE,
 
  i.ID_ItTyp = r.ID_ItTyp,
 
  i.ID_ItOpt = r.ID_ItOpt,
 
  i.ItOpt_Descr = iif(r.ItOpt_Descr IS NULL,i.ItOpt_Descr,r.ItOpt_Descr),
 
  i.ItOpt_Sort = r.ItOpt_Sort,
 
  i.ID_ShipCost = r.ID_ShipCost,
 
  i.PriceBuy = r.PriceBuy,
 
  i.PriceSell = r.PriceSell,
 
  i.PriceList = r.PriceList,
 
  i.GrpCode = r.GrpCode,
 
  i.GrpDescr = r.GrpDescr,
 
  i.GrpSort = r.GrpSort,
 
  i.CatSfx = r.CatSfx
 
WHERE r.ID_Item IS NOT NULL;
 
</sql>
 
 
 
Changes:
 
* Must clear isPulled and isDumped, in case pulled items are returned to service
 
===(Step 5) qryVb_Items_update_final===
 
* Clear isInPrint flag for cat_items not found in calculated in-print listing
 
* Set isForSale for cat_items with stock for sale
 
* Update stock quantities for all cat_items
 
<sql>UPDATE
 
  (cat_items AS i LEFT JOIN qryCtg_build AS r ON r.ID_Item=i.ID)
 
  LEFT JOIN v_stk_items_remaining AS s ON s.ID_Item=i.ID
 
SET
 
  i.isInPrint = nz(r.isInPrint),
 
  i.isCloseOut = nz(r.isCloseOut),
 
  i.isForSale = nz(r.isInPrint)
 
      OR nz(r.isCloseOut)
 
      OR (nz(s.QtyForSale) > 0),
 
  i.qtyInStock = nz(s.QtyForSale);
 
</sql>
 
===(Step 6) qryVb_Items_mark_updated===
 
<sql>UPDATE
 
  data_tables
 
SET WhenUpdated=Now()
 
WHERE Name="cat_items"</sql>
 

Latest revision as of 11:07, 12 June 2017

Version

This is a tricky process which has been revised multiple times.

  • 2017 version - 2016 code apparently never really got finished, and the Items table needs some flag changes
  • 2016 version - webified version of 2010, with rules finally documented
  • 2010 version: see maint/build-cat.php
  • 2009 version - SQL statements executed directly from PHP code
  • 2008 version - started in 2007 - a set of stored queries called from a stored procedure
  • 2006 version

It's interesting to note that I originally thought of SCM Groups as groups of Titles -- an explanation from the VbzCart/tables page on 2008-02-17 (and only removed on 2016-02-01) says:

The key concept here is "catalog title groups" (CTGs). A CTG is a set of titles which are all available with the same set of options (e.g. sizes) at the same prices (e.g. $10 S, $11 M-XL, $12 2XL). The final vbz catalog (cat_items) is the result of a sort of vector multiplication of Titles (cat_titles) and CTGs plus any items in stock.

This conceptualization no longer works, as a SCM Title may have one or more SCM Groups -- e.g. if it has a set of standard sizes (like S-3X) but is also available in super-large sizes (4X+).