Hi Sunil,
Thanks for the clarification. Based on some initial testing, it looks like the where filter on the nested Variants collection only controls which products are returned. It does not scope the nested field used by orderBy.
For example:
where: {
Variants: {
Market: { eq: "US-WHOLESALE" }
}
}
orderBy: {
Variants: {
Price: {
Amount: ASC
}
}
}
The filter correctly limits the products to those having a US variant, but the sorting still considers the minimum price across all variants, including variants from other markets.
I don't see a supported orderBy syntax that allows a filter to be applied specifically to the nested collection used for sorting.
For market-specific price sorting, a few possible approaches would be:
Market-specific sortable fields – for example, USWholesaleStartingPrice, CAWholesaleStartingPrice, etc.
Market-wise indexing – index the product/variant data as a separate document per market, such as Product + Market + StartingPrice. This would allow filtering by market and sorting directly by StartingPrice.
Separate search/index model – create a search-oriented model where the market-specific price is already calculated during indexing.
The market-wise indexing approach seems particularly useful when the number of markets is dynamic or when we need to support other market-specific filters such as inventory, availability, promotions, etc.
It would be useful to know if Optimizely has any planned support for filtering the nested path used by orderBy, similar to the nested sorting/filtering capabilities available in Optimizely Find.
I tested this with a minimal custom Optimizely Graph Source, separate from Commerce, and was able to reproduce the same behavior.
I used three products with nested Market/Price values:
A: US=450, CA=100B: US=300, CA=500C: US=350, CA=250
With where Market = US and nested orderBy Price ASC, Graph returned A, C, B, which corresponds to the minimum price across each product's complete variant collection (100, 250, 300) rather than the filtered US prices.
I then tested the market-wise indexing approach suggested above by indexing one document per Product + Market. With Market and Price as fields on that document, the same query returned the expected B(300), C(350), A(450).
I also tried keeping Market + Price together in another nested collection, but that still produced the original behavior. So simply changing the nested structure doesn't appear to solve it; the sortable market-specific value needs to be represented as a scalar on the document (or precomputed into a market-specific field).
For CMS 13.1.0+, another possible workaround could be to use the Graph Indexing Conventions API to add a computed market-specific price field at indexing time using IncludeField(), with IndexingType.Queryable.
For example, the computed field could resolve the price for a particular market from the variants and expose it as a scalar such as USWholesaleStartingPrice. The Graph query could then sort directly on that scalar instead of the nested multi-valued Variants.Price.Amount field.
This seems suitable when the set of markets is relatively fixed. For a large or dynamic set of markets, indexing a separate Product + Market document would probably scale better.
Hi Optimizely Team,
I’m trying to implement market-scoped price sorting using Optimizely Content Graph and have run into an issue where
orderByon a nested field does not appear to respect the filter applied to the nested array.Scenario
We have a
GenericProducttype with a nestedVariantsarray. Each element in the array represents one purchasable variant of a product and carries its ownMarket,Price, andAvailableInventoryvalues.Simplified schema:
Sample documents:
The Query
A user authenticated to
US-WHOLESALEonly searches for products and requests results sorted by Starting Price ascending:Problem Statement
The
whereclause correctly restricts which products appear — only products that have at least oneVariantsentry satisfyingMarket = US-WHOLESALEare returned. This works correctly.When
orderBy: { Variants: { Price: { Amount: ASC } } }is applied, we expect the sort to use only the variant(s) that also satisfy the market filter — i.e., the minimum price acrossUS-WHOLESALEvariants only.Expected sort order for the US-WHOLESALE user
What actually happens
The
orderByon the nested field is not scoped to the market filter. Content Graph evaluates the sort using the minimum price across all nestedVariantsregardless of market, including variants the user cannot access.The displayed Starting Price for PROD-A (after client-side market filtering) is $450.00, but it ranks 2nd — above PROD-B at $420.00. The sort order is incorrect for the user's accessible market.
Request / Question
Is there a planned or existing mechanism in Content Graph's GQL
orderBysyntax to apply a filter on the nested path used for sorting?If not, is there a recommended pattern for market-scoped price sorting on a
GenericProducttype with a nested variants array, without fetching all documents client-side?Environment
Optimizely CMS: 12
Optimizely Commerce: 14
Content Graph packages:
Thanks in advance for any guidance on the supported query syntax, limitations of nested sorting, or recommended approach for this scenario.