Hello, I'd like to reopen the discussion regarding the limitation on

sort_by

(currently limited to only 3 clauses). I understand this is a deliberate constraint. However, we're looking to replace Algolia's Merch Studio (premium), and being able to do this directly through curations would be a real game-changer for us. Of course, merchandising rules often involve multiple fields. If it were possible to allow more than three clauses (perhaps via a server-side configuration, even at the cost of some performance), it would definitely be a strong advantage. This would allow us to apply complex merchandising rules to e-commerce catalogs without having to create additional indexes — enabling real-time execution of merch rules via curation, directly by business teams. Don't hesitate to forward me elsewhere if it's not the right place to open this discussion.

Hey there, would you like to describe the use-case and how you've been handling it up to this point with Algolia? Maybe we can provide some insight on how you can achieve this with the 3 field rule

Hey, yes of course, Let's say I have a fairly standard e-commerce catalog with some denormalized fields: •

brandOrder

, •

price

, •

analyticsProductViews

, •

catalog

array field (which is a list of `catalog_id`s the product belongs to), • and a

product_id

, of course In Algolia Merch Studio, you can create merchandising rules that get triggered under certain conditions (for example:

catalog.id := 123

, or more complex triggers based on filter_by for example), and apply a set of merchandising actions dynamically — such as sorting by

price

,

brandOrder

, pinning specific `product_id`s, hiding others, etc. So when a query is made (e.g. for a given catalog ID), if a configured trigger applies, the merchandising rules are applied on the fly. This gives business teams a lot of autonomy — as long as the data is clean and indexing is complete, they can work independently

Curation rules are the equivalent feature in Typesense. They both can achieve this via filters, tags, or query. Is there something missing in terms of UI / UX in Typesense cloud or a feature missing in Typesense entirely on this front?

The trickier part is giving business users control over the full range of

sort_by

options — even though we'll enforce some constraints to keep things manageable. Right now, what I’m experimenting with (and it’s working fairly well) is indexing a separate collection, where a ranking score is precomputed based on the business rule. Then, I create a curation rule that joins with this new collection to apply the custom sorting. The downside, though, is that the whole process — and especially the rule configuration interface — becomes less real-time. Since I need to reindex this rule at creation time, it prevents me from offering immediate preview capabilities in the business admin interface, for instance

Sorry, but I think I'm missing something here, haha! The use-case you described is about merchandising and curation rules, where does sorting on more than 3 fields simultaneously come into play?

Yes exactly.

Mind you, the order of the

sort_by

fields are tie-breaking, meaning that each one is going to be applied if there are two or more documents with the same value on that sort field. You could look into using the

_eval

clause to sort based on filter conditions: https://typesense.org/docs/guide/ranking-and-relevance.html#ranking-based-on-conditions Or just have one popularity / aggregated score field based on that order you mentioned, at indexing time. No need to copy the data to another collection and JOIN for this

As the product collection is quite important, that's why if put it in other collection. and also because we want to abstract merch rules from product indexation (because the last one could quite complex, based on product offering)

> A quick note for the future (potential curation improvment) — not critical for the current use case, but still worth mentioning: > It seems that rules (which trigger curations) — and more specifically the

filter_by

condition — in Typesense currently only work with exact matches. We've taken note of that, yeah. It's a bit more nuanced than that though, sadly, since filters can be complex and include arrays etc, so there's still planning needed to be done if we do end up implementing this feature

Thanks for the last point, and I understand well this point.

As the product collection is quite important, that's why if put it in other collection.

and also because we want to abstract merch rules from product indexation (because the last one could quite complex, based on product offering)

Then a one-to-many relationship with that collection would be ideal, without any redundancy in terms of product details (not saving the title or description twice, just saving the score and the reference to the id of the product). Although this will have a performance cost, since joining is done at search time, not during indexing time

As for the

eval

mechanism — it won't work in this case, since we're actually dealing with tie-breaking, not strict filtering. In fact, I do not try to search anything, but display full catalog page views, so without any search query but with specific merchandising

Thank you providing all the details / context. I agree that 3 sorting fields could be a limitation, but this is a restriction that's not easy to parameterize at the moment. > e.g the business team want a rule with a sort_by on price, then brandOrder, the stockQuantity, productViews Let me provide one rationale for this restriction (apart from performance) and then a work around which will help: What we have noticed in practice is that often beyond 3 fields, the tie-breaking has minimal effect o ranking order. In the above example, once you sort on price, brand and stockQuantity, it will be very rare for a product to tie on stockQuantity to require productViews to break that tie for ranking. Also, here's is one way to combine 2 fields into a single int64 field -- code in python below, but easy to adapt to any language of your choice.

def combine_to_64bit(val1, val2):
    """
    Combine two 32-bit integers into a single 64-bit integer using bit shifting.
    
    Args:
        val1 (int): First value that will occupy the high 32 bits
        val2 (int): Second value that will occupy the low 32 bits
        
    Returns:
        int: 64-bit integer combining both values
    """
    # Shift first value left by 32 bits
    high_bits = val1 << 32
    
    # Combine with second value using bitwise OR
    result = high_bits | val2
    
    return result

Using this approach you can actually "pack"

stockQuantity

and

productViews

into a single field and it will also preserve the sorting order like you would get with 4 sorting fields. This computed field can be indexed as part of the document and used in sort_by clause.

Thanks @Kishore Nallan and @Fanis Tharropoulos Hopefully, I will be able to share with you soon for who I work, in the built-with-typesense chat