Make the dfuse Query Language less rigid

[scottoau]

Depending on the exact contracts we are looking for, the "wrong" pairs could be impossible to find. Right now, the same results "could" be found just because one set of actions in a contract doesn’t exist in the others. This is a problem only when the same action exists on both contract and we want only those for one or the other.

The current best way to go around the limitation is to perform multiple OR s on contract/action and filter on the client side: (receiver:account1 OR receiver:account2) (action:two OR action:three OR action:second) and filter out unwanted pairs when receiving for example account1/second.

That’s extra code that could be saved by allowing the query language to allow constructions of the form (receiver:account1 action:two) OR (receiver:account1 action:three) OR (receiver:account2 action:second).

[abourget]

Yes, the current language was deliberately limited to keep our options as to which backend we'd chose, had we wanted to switch.

The backing engine (blevesearch) can handle all of those queries and much more. What you propose makes a lot of sense, and doesn't even complexify the requirements to the backend that much.

We'll put that on the list. Keep us posted if this becomes a major challenge for you.