Event matching policy
It is possible for the windows for a given key to contain multiple sets of events that, each taken in isolation, would match the defined event pattern. In this case, the matching policy determines which of the candidate event sets is the match set that triggers the query. There are two event matching policies:
Recent — This is the only policy followed for queries that to not specify the
every keyword, that is, they do not specify aggregate functions.
Every — This is the only policy followed for queries that specify the
every keyword. That is, they specify aggregate functions.
For both policies, the match set must include the latest event. The latest event is the event that was most recently added to the set of windows identified by a particular key.
For the recent matching policy, to identify which candidate match set triggers the query, the correlator compares the times of the second-most-recent events in the candidate event sets. If one of these events is more recent than its corresponding event(s) then the candidate event set it is in is the match set. However, if two or more candidate event sets share the second-most-recent event, then the correlator compares the times of the third-most-recent events in those candidate event sets. The correlator continues this until it finds an event that is more recent than its corresponding event(s) in other candidate event set(s). The candidate event set that becomes the match set is referred to as the most recent set that matches the event pattern.
Once the correlator determines which candidate event set is the match set, it ignores the order of any earlier events in any event sets. This means that it is possible for the most recent set of events to contain an event that was added earlier than an event in a set that is not the most recent set. The following event definitions and sample query illustrate this.
event APNR {
// Automatic Plate Number Recognition
string road;
string plateNumber;
integer time; // Represents time order for illustration purposes
}
event Accident {
string road;
}
event NotifyPolice {
string road;
string plateNumber;
}
The following query uses these events:
query DetectSpeedingAccidents {
inputs {
APNR() key road within(150.0);
Accident() key road within(10.0);
}
find APNR:checkpointA -> APNR:checkpointB -> Accident:accident
where checkpointA.plateNumber = checkpointB.plateNumber
and checkpointB.time - checkPointA.time < 100
// Which indicates the car was speeding
{
emit NotifyPolice(accident.road, checkpointA.plateNumber);
}
}
Suppose the following events are in the query windows:
APNR("MyRoad", "2N2R4", 1000)
APNR("MyRoad","FAB 1", 1010)
APNR("MyRoad","FAB 1", 1080)
APNR("MyRoad","2N2R4", 1090)
Accident("MyRoad")
There are two candidate event sets:
Coassignment identifier | A candidate event set | Another candidate event set |
checkpointA checkpointB accident | APNR("MyRoad", "2N2R4", 1000) APNR("MyRoad", "2N2R4", 1090) Accident("MyRoad") | APNR("MyRoad","FAB 1", 1010) APNR("MyRoad","FAB 1", 1080) Accident("MyRoad") |
Both sets match against the single Accident event. The next most recent events are APNR("MyRoad","2N2R4", 1090) and APNR("MyRoad","FAB 1", 1080). The APNR("MyRoad", "2N2R4", 1090) event is more recent. Consequently, after the Accident event is added to its window, there is a match and the match set includes the Accident event and the 2N2R4 APNR events. This is the most recent set of events.
In this example, in the most recent set of events, the earliest event, APNR("MyRoad", "2N2R4", 1000) is earlier than the earliest event, APNR("MyRoad", "FAB 1", 1010), in the other set of events.
