When emulating complex types using the approach mentioned in that article, you can filter the same way you would with "flat types". However, this brings some limitations.
One of the limitations of emulating complex types with collections is that you can’t perform filters on "sub-documents" easily. Taking the example from the article, imagine you have locationsId
and locationsDescription
fields. If you perform a filter like this:
$filter=locationsId/any(id: id eq '4') and locationsDescription/any(d: d eq 'Home office')
You may get more results than you wanted. For example, you may get documents that have a locationsId
of 3 with the description "Home office", or a locationsId
of 4 with a different locationsDescription
. This is because the two clauses above must use separate lambda expressions, so the comparisons are not done to the same logical 'sub-document'. One workaround mentioned in the article is to index combinations of values together. If you had a locationsCombined
field, you could filter it like this (assuming you indexed the values using |
as a separator):
$filter=locationsCombined/any(c: c eq '4|Home office')
This still has some limitations on what you can express inside the lambda though.
Fortunately we are working on native support for Complex Types, so soon such workarounds will not be necessary.
Edit
To address your specific example, assuming you're modeling your data in a "flattened" schema per the article, you can filter on tags like this:
$filter=subscriptionTags/any(t: t eq 'azure')
And you can filter on billType
like this:
$filter=subscriptionBillType eq 'month'
This "flattening" won't be necessary once the Complex Types feature is generally available.