Part 2 – The Generic Workaround
The obvious solution is to make a loose query that returns a superset of what you’re looking for, similar to the query in my first sample:
/odata.svc/CustomMetas?$filter=KeyName eq 'color' and StringValue eq 'blue'&$expand=Component/ComponentPresentations
Then on the application side filter out the results the old fashioned way (loop: foreach “blue” component check if it is also round, else skip). It’s still unwanted bytes over the wire.
This is actually OK most of the time because in the majority of scenarios you might only have a few Component Presentations published even with the loose set of Custom Metas. And if you have 100,000 DCPs in your broker, then it’s probably time to unpublish some stale content.
Side Note: Keep the content in the Broker DB up-to-date for optimal performance. Unpublish any content that is stale and no longer shown to the visitors.
In some cases the lesser evil might be to choose ComponentPresentations as the entry point with the $filter set on the Template, and finish refining your set in your app. For example:
/odata.svc/ComponentPresentations?$filter=TemplateId eq ‘83'&$expand=Component/CustomMetas
(note: 83 is just a CT ID in my system)
then loop: for each ComponentPresentation if it contains CustomMeta color=blue and CustomMeta shape=round.
You will need to perform an analysis on your use case. Will you have more Components of a given Schema tagged with CustomMetas vs. ComponentPresentations of a given Template? The goal here is to choose the approach yielding the smaller resultset to be sent across HTTP.