2022-06-05 variantProduct SearchResults: Difference between revisions
(Created page with "Service - Variant Manager 2022-06-05 2022-06-05") |
No edit summary |
||
Line 1: | Line 1: | ||
[[Service - Variant Manager]] | [[Service - Variant Manager]] | ||
= Overview = | |||
variantProduct type want to mix products and variants into one searchResult set so they can be viewed by client together. | |||
Only want to show products that are not part of any variants, products that are part of variants show the variant instead, but the variant details come from only matching products, not all of that variants children. | |||
Try to allow for variant filters as well, this would first find products that match the product level filter, but then remove (or add - but how to choose which products make up the variant data?) any variants that do not match the variant filter. | |||
= Idea = | |||
Have filterType variantProduct which has two child filterTypes, variants and products. variant filterType can duplicate the product filter as a child of it, this achieves a standard product search across variant and stand alone products. | |||
product child filter adds an element that removes any products that are a child of any variants. | |||
variant filterType findData fields receive the child product filter and for each variantId, and uses this to find only filtered for products to aggregate into variant values. | |||
If we wanted to add additional variant specific filter elements, this could be used to remove variantIds, but could also add variantIds that have no matching child products found, perhaps when variant findData tries to find any matching child products and does not, we generate the variant's aggregate value from all child products? | |||
translate ids from product or variant up to variantProduct type could add a code to the id eg v_ or p_ | |||
variantProduct findData chooses whether to send on to either variant or product to get result depending on code included in the dataId | |||
= Flow = | |||
== variantProduct searchResult received == | |||
* includes a variant child filter (with optional product child filter) | |||
* includes a product child filter (with optional "noParentVariant" filter element) | |||
== variantProduct complexFilter sends to child filters == | |||
* sends out request to variant and product complexFilters | |||
* variantProduct filterType will have no other possible filter elements, only the two child filter types | |||
== variant complexFilter == | |||
* will return variantIds of variants that have any matching productIds if it has a child product filter, and any additional variants found using other elements. | |||
== translateIds to variantProduct == | |||
* add code according to child filter type | |||
== variantProduct searchResult == | |||
* receives the list of productIds and variantIds that match the child complex filters | |||
* sends these to variantProduct level findData | |||
* includes the two child filters in the findData request | |||
== variantProduct findData == | |||
* if is product dataId, sends request to product findData to find the matching field, including any required child filters eg sellOffer | |||
* if is variant dataId, sends request to variant findData to find the matching field, including product child filter | |||
== Child Type findData == | |||
* uses any lower level filters to find the data required, eg variant type would use the product filter to only aggregate matching product values (the child product filter should already be cached from original complexFilter requests) | |||
* findData may pass down filters as required, eg thumbnail field might pass on media child filters, or product price fields might pass on sellOffer child filters | |||
= notes = | |||
Results could be spammed by placing a product into multiple variants, all variants would show up as one record in results | |||
= old ideas = | |||
[[2020-10-12 - Search Result add hooks]] | |||
[[Category:Working documents| 2022-06-05]] | [[Category:Working documents| 2022-06-05]] | ||
[[Category:Working documents - Variant Manager| 2022-06-05]] | [[Category:Working documents - Variant Manager| 2022-06-05]] |
Latest revision as of 13:04, 5 June 2022
Overview
variantProduct type want to mix products and variants into one searchResult set so they can be viewed by client together.
Only want to show products that are not part of any variants, products that are part of variants show the variant instead, but the variant details come from only matching products, not all of that variants children.
Try to allow for variant filters as well, this would first find products that match the product level filter, but then remove (or add - but how to choose which products make up the variant data?) any variants that do not match the variant filter.
Idea
Have filterType variantProduct which has two child filterTypes, variants and products. variant filterType can duplicate the product filter as a child of it, this achieves a standard product search across variant and stand alone products.
product child filter adds an element that removes any products that are a child of any variants.
variant filterType findData fields receive the child product filter and for each variantId, and uses this to find only filtered for products to aggregate into variant values.
If we wanted to add additional variant specific filter elements, this could be used to remove variantIds, but could also add variantIds that have no matching child products found, perhaps when variant findData tries to find any matching child products and does not, we generate the variant's aggregate value from all child products?
translate ids from product or variant up to variantProduct type could add a code to the id eg v_ or p_
variantProduct findData chooses whether to send on to either variant or product to get result depending on code included in the dataId
Flow
variantProduct searchResult received
- includes a variant child filter (with optional product child filter)
- includes a product child filter (with optional "noParentVariant" filter element)
variantProduct complexFilter sends to child filters
- sends out request to variant and product complexFilters
- variantProduct filterType will have no other possible filter elements, only the two child filter types
variant complexFilter
- will return variantIds of variants that have any matching productIds if it has a child product filter, and any additional variants found using other elements.
translateIds to variantProduct
- add code according to child filter type
variantProduct searchResult
- receives the list of productIds and variantIds that match the child complex filters
- sends these to variantProduct level findData
- includes the two child filters in the findData request
variantProduct findData
- if is product dataId, sends request to product findData to find the matching field, including any required child filters eg sellOffer
- if is variant dataId, sends request to variant findData to find the matching field, including product child filter
Child Type findData
- uses any lower level filters to find the data required, eg variant type would use the product filter to only aggregate matching product values (the child product filter should already be cached from original complexFilter requests)
- findData may pass down filters as required, eg thumbnail field might pass on media child filters, or product price fields might pass on sellOffer child filters
notes
Results could be spammed by placing a product into multiple variants, all variants would show up as one record in results