siddhi

How to detect patterns involving multiple unordered conditions

Let's say I want to detect a pattern like this:

from every A -> B or C or D  # P0, not accepted by Siddhi

where B, C, and D can happen in any order. From the docs:

Siddhi can only logically correlate two conditions at a time using keywords such as and, or, and not. When more than two conditions need to be logically correlated, use multiple pattern queries in a chaining manner, at a time correlating two logical conditions and streaming the output to a downstream query to logically correlate the results with other logical conditions.

So, I guess that I should do something like this:

from every A -> B  # P1
from every A -> C  # P2
from every A -> D  # P3

However, the above rewrite is not strictly equivalent to the original pattern. For example, given the sequence of events

A1 D1 C1 B1

P3 will trigger after D1, P2 after C1, and P1 after B1, whereas the original pattern P0 would only trigger once after D1 (assuming that P0 was valid).

Similarly, how should one deal with patters of the form

from every A -> B and C and D  # not accepted by Siddhi either

In general, are there plans to support correlating more than two conditions at a time? Otherwise the implementation of these patterns can get quite messy and error-prone. In the meantime, the documentation could be extended a bit to illustrate how to implement a couple of simple cases as the ones considered in this question.

Solution

  • Thank you for the feedback on documentation, we will incorporate complex example in the new Examples section currently in the progress

    Answered in Github

    Yes, it is a design level limitation in Siddhi pattern implementation. There are some plans to improve this and it is in our roadmap.

    If you consider your example, (A and B and C) or (D and E and F) then you have to write 5 pattern queries as shown below.

    A and B -> output1
output1 and C -> output2
D and E -> output3
output3 and F -> output4
output2 or output4 -> finalOutput

    Likewise, we have to write the queries into multiple subqueries based on the requirement. I do understand that it adds some burden but unfortunately, this is the only option for now.