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.

see Per Service Schemas#searchResultGenerated

objectSchema sets generatedBy to searchResultGenerated
objectSchema sets searchResultGeneratedFlowType for generating the searchResult data
perhaps searchResultGeneratedFlowType throws error if initial request does not include variantId/productId in requiredData, because these are required for any links used (maybe only if have other linkPath requiredData, but we always save variantId/productId in requiredData so maybe always throw error)
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, adding requireData for the variantId and productId
identifier for variantProduct is automatically searchResultData identifiers
has relationships (storageType = lambda) to variant and product which uses the requiredData record, this allows frontend to use schema to link either to variant or product for independant results for each
if want single result field, eg maxPrice, add a field to the variantProduct objectSchema, this will force requiredData to pass to a flow to find value (which checks already exists in requiredData, if not find depending on is variant or product and place in requiredData)
maybe have syncronous flows in searchResult that eg create/check requiredData, so external flows not need to adjust data directly
if both variants and products link to productAttributes, then we could have a relationship from variantProduct to productAttribute where the translateId flow passes to correct link, this would allow connecting links (eg to translations) to be set as normal on frontend

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

2025-07-29 - variantProduct SearchResults

Contents