Lexicographical targeting.

[wuguishifu]

Describe the feature request

Lexicographical sorting for strategy targets such as STR_GT, STR_LT, STR_GTE, STR_LTE, STR_BETWEEN.

Background

I have a few tests that have a LOT of strategies because I need to target specific sets of data (e.g. subscription product + expiration date past certain time + app version greater than specific version). So right now my tests look like this:

Strategy 1

• subscription product IN com.example.mysubscription
• expiration_date NUM_GT 20250101000000
• app_version SEMVER_GT 13.0.99

Strategy 2

• subscription product IN com.example.myothersubscription
• expiration_date NUM_GT 20230130000000 (different expiration date)
• app_version SEMVER_GT 13.0.99

So basically, I would like to be able to target based on groups of items.

Solution suggestions

A good pattern for doing this would be using a lexicographical sort. This is similar to how AWS DynamoDB can filter primary keys and makes it very powerful. So for example, I could say like:

value STR_GT "{product ID}#{expiration date}#{app version}"
AND
value STR_LT "{product ID}#{expiration date}"

which would then correctly check for all of these fields at the same time.

A better option would be something like

value STR_BETWEEN "{value 1}" "{value 2}"

so the strategy targeting could be simplified.

Then, it would be nice to be able to group multiple with an OR (similar to IN) so you could do like:

value IN
  - STR_BETWEEN a b
  - STR_BETWEEN c d
  - STR_BETWEEN e f

and this would let you condense a lot of complex strategy queries into a single strategy.

[gastonfournier]

Thanks for raising this. It’s a really nice feature request, and we see the value.

At the moment, our main focus is on releasing and stabilizing Yggdrasil, which is the engine that evaluates rules and constraints. We’re in the process of rolling this out across the SDKs, and once that work is complete and stable, we’ll be in a good position to look at adding new types of constraint or rule evaluation (such as the one you’re suggesting).

One thing to keep in mind is that your suggested approach may reduce flexibility in some cases. With the current granular model, you can change how you evaluate context without touching your codebase, opting in or out dynamically. With the proposed model, changes would require updating your code. That said, your suggestion definitely makes sense, and how to use it in practice would be up to you.

If you’re interested in contributing to building this feature into Yggdrasil, let us know. Meanwhile, we'll open an issue in that repository to keep track of the request, while this one will be to remind us to also implement the necessary changes in Unleash.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.