Change the behaviour of non-group predicates being OR-ed with named groups

[ivanopagano]

Relates to #516 The current solution considers predicates with no explicit group as being part of a default anonymous group, hence they're always combined with other, named, groups using "OR" semantic.

We might want to consider non-grouped predicates as a separate group that is combined with others using AND semantic only e.g. pa, pb, pc[g1], pd[g1], pe[g2] would translate to pa ∧ pb ∧ ( (pc ∧ pd) ∨ pe )

which easily allows to express a combination of "common filters" to be applied to any alternative union of other groups.

To regain the currently existing semantic it would be enough to put every predicate in some group, i.e. pa[g0], pb[g0], pc[g1], pd[g1], pe[g2] translating to (pa ∧ pb) ∨ (pc ∧ pd) ∨ pe

[vishakh]

@ivanopagano Maybe I misunderstand but do we not AND ll predicates currently?

Also, in common convention, ^ means AND and V mean OR. Do you also follow this convention or its reverse?

Finally, could we not achieve clarity by simply nesting predicates and allowing the user to define the operator?

[ivanopagano]

Also, in common convention, ^ means AND and V mean OR. Do you also follow this convention or its reverse?

yes, I do follow that convention

[ivanopagano]

Finally, could we not achieve clarity by simply nesting predicates and allowing the user to define the operator?

we could, but doing arbitrary nesting increases the level of complexity and would require - if I'm not mistaken - a different syntax than the current one, which simply assigns predicates to groups and conventionally composes the groups

[vishakh]

@ivanopagano Could you provide some concrete examples of hypothetical JSON queries and how they would work?

[ivanopagano]

@vishakh

Suppose we want a number of different transactions, all those going out from source tz1x or tz1y, but we're only interested in those happened after 2020-05-01

With the current model if we write a filter like

"predicates": [
  {
    "field": "kind",
    "operation": "eq",
    "set": ["transaction"],
    "inverse": false
  },
  {
    "field": "timestamp",
    "operation": "after",
    "set": [1588284000000],
    "inverse": false
  },
  {
    "group":"g1",
    "field": "source",
    "operation": "eq",
    "set": ["tz1x"],
    "inverse": false
  },
  {
    "group":"g2",
    "field": "source",
    "operation": "eq",
    "set": ["tz1y"],
    "inverse": false
  }
],

What we would get is that the "ungrouped" predicates: kind and timestamp, will be considered a separate group and OR-ed with the others, thus the results will be:

• all transactions happening after 2020-05-01 OR
• any operation with source "tz1x" OR
• any operation with source "tz1y"

which is clearly more than we want. Current semantic is thus

(kind AND timestamp) OR (source1) OR (source2)
       ^^^^^             ^^^^^         ^^^^^
      nogroup              g1          g2

Instead with the new semantic, the "ungrouped" predicates will be considered part of any of the group, being intersected with the others, like:

• transactions happening after 2020-05-01 AND
• (source is "tz1x" OR "tz1y")

Tis would translate to the following semantic

kind AND timestamp AND ((source1) OR (source2))
       ^^^^^             ^^^^^         ^^^^^
      nogroup              g1          g2

This allows to easily create a "common filter" and alternative choices that share the common part.