2025-07-29 - variantProduct SearchResults
Revision as of 14:18, 29 July 2025 by Sven the Barbarian (talk | contribs) (Created page with "Service - Variant Manager Service - Search Results = Overview = * Catalog lists of listings on frontend want option to show variants mixed with stand alone listings that match filters * Want to be able to use SearchResult/SortResult services so can use on catalog, table output, graph output etc * Form could show data but variantProduct has no editable fields * Want linkPath values for variant to only show data for child products that pass filters = idea 1 (tr...")
Overview
- Catalog lists of listings on frontend want option to show variants mixed with stand alone listings that match filters
- Want to be able to use SearchResult/SortResult services so can use on catalog, table output, graph output etc
- Form could show data but variantProduct has no editable fields
- Want linkPath values for variant to only show data for child products that pass filters
idea 1 (try this)
Create a new setting in objectSchema that specifies an objType only exists in searchResult, the searchResultData and requiredData is saved using a flow.
- objectSchema has searchResultGenerated setting
- objectSchema sets flowType for generating the searchResult data
- cannot be shown in forms (can perhaps show, limited to specific identifier for searchResultData)
- can be used in tableOutput
- original request can enter SortResult, pass to searchResult at which time a searchResultMain is created and the flow is invoked which saves all data up to processRequiredData complete
- flow creates 2 processSearchResult requests, product and variant, after they complete the data is combined into the final searchResultMain data
- variant as the base objType, all linkPaths are specified according to variant as the top level objType
- when combine searchResults product requiredData gets transferred into the matching variant fieldnames/requiredData
- have additional fieldnames, such as type ("variant" or "product"), these can be added automatically to requiredData
- objectSchema sets available links etc to match variant objType
- objectSchema sets what filter/requiredData sets are needed (for variant and for product) (not sure about this)
- perhaps use extend setting to inherit fields and relationships from variant, or another setting specific for searchResultGenerated = true
- perhaps request is generated using variant schema, and flow automatically removes variant level filters/linkSteps when creating product request
idea 2
Frontend managed, don't like this option as no variantProduct data stored on backend for search/sort.
- frontend creates two requests, one for products that match and have no variantion links, one for variants that have products that match
- frontend combines them
idea 3
Have objType for variantProduct and translateIds that converts product and variant into it. Incomplete idea, many possible issues, might need a record in graph.
- have a translateIds lambda from variant <> variantProductId, and product <> variantProductId
- ids only get saved into translateIds table and searchResult etc tables (will work with no storageTags?)
- maybe store variantProduct in graph, instance links to a variant or to a product
- do separate requiredData/linkPaths for variant and for item
idea 4
Make new objTypes to handle relationships.
varProRequest objType
- has it's own uuid
- is parent objType that records search params
variantProduct objType
- is one listing result, product or variant
- partition key is varProRequestId
- sortKey identifies type (P/V) and identifier
varProDataValue objType
- translateIds similar to orderPrice
- requestProperties include varProRequestId and linkPath for product and for variant
- can return multiple values (eg attributes)
- stores multiple varProDataValueIds in translateIds
- each varProDataValue record stores the variantProductId and value