Closed redmitry closed 1 year ago
@redmitry I don't think this is a good idea right now especially reading the last comments in the discussion. The logic w/ the sequence is compact but prone to mis-interpretations if you don't read the spec well... and then the sequence itself is problematic if using POST since all kinds of nefarious reordering might happen.
IMO we should for now just document the "same scope" concept and start a scout team for 2.n filters.
The filters are passed in array so no ordering problem should happen. The rule is quite simple - group ORs and use AND for groups. It's compatible with current spec.
Hi @redmitry . Although I see this as a great proposal that has to be studied so we can add OR logic to our beacon specifications, I don't think this should be yet merged into any branch as it is a sensitive discussion that still needs time to get a consensus. As we seen in the previous issue discussion, beacon v2 right now is only prepared to accept AND filters without breaking the specifications and if we want to add OR logics into our queries we have to be very accurate, so I feel this is a thing that maybe needs other kind of possible solutions before accepting the one that fits best.
Proposal for the #100
The simple solution is to include optional "logic" property to the query filter. No "logic" property is treated as 'AND'
The GET query like filters=A,B|C|D would lead to POST filters:
[{"id": "A"}, {"id": "B"}, {"id": "C", "logic": "|"}, {"id": "D", "logic": "|"}]