daniel-chambers
commented
4 years ago Table storage itself is extremely restrictive in terms of the queries it allows you to write. "Contains" is not one of the operators that it allows, and transforming a Contains into a series of ORs is anti-pattern of how one should be using table storage, as it'll result in scans that don't use the indexes on the tables. So I'd say doing it is hard... on purpose, because one probably shouldn't be doing it. If one's requirements dictate flexible querying, table storage is the wrong tool for the job.
Check out this documentation from Microsoft about appropriate query patterns. In particular, they mention ORing RowKeys as an anti-pattern that results in an index scan, and I imagine doing it on a partition key would be even worse. :(
aggieben
Description
The limitation of the query module to only the few boolean operators is very restrictive. I'd like to be able to query something with an expression like this:
My first thought was to try to build the expression with a function with the type
'a seq -> Expr<T -> Metadata -> bool>that would create expressions likesysprops.PartitionKey = value1 | sysprops.PartitionKey = value2 | ....One might at this point suggest that I should choose a different partitioning strategy to make this easier, but it really doesn't fix the underlying issue: I want to query for a range of rows; which property is involved in the comparison isn't really the issue.
I would think this is very common., but trying to build an parameterized
Expr<T -> Metadata -> bool>quite a chore (and impossible to do with splices, I think). Is there a recommended way to deal with queries like these?