这是因为嵌套上下文不是 OR 关系。对于 OR,请使用本示例末尾的模式。
假设事件类型 AStart、AEnd、BStart、BEnd 和 C。
create context CtxSampleNestedContext
context SpanA start AStart end AEnd,
context SpanB start BStart end BEnd;
context CtxSampleNestedContext select count(*) from C;
创建上述 EPL 语句后,引擎开始仅查找 AStart 事件,而不查找 AEnd、BStart、BEnd 或 C 事件。
假设 AStart 事件接下来到达:
- 引擎停止寻找 AStart 事件。
- 引擎开始寻找 AEnd 事件,因为这意味着当前 SpanA 生命周期的结束。
- 引擎开始寻找 BStart 事件,以检测 SpanB 生命周期的开始。
在该场景中,假设 BStart 事件到达。从逻辑上讲,这是 SpanB 生命周期的开始:
- 引擎停止寻找进一步的 BStart 事件。
- 引擎开始寻找 BEnd 事件,因为这意味着当前 SpanB 生命周期的结束。
- 引擎一直在寻找 AEnd 事件,因为这意味着当前 SpanA 生命周期的结束。
- 引擎开始寻找 C 事件,现在开始计算每个到达的 C。
在该场景中,假设 BEnd 事件到达。从逻辑上讲,这是 SpanB 生命周期的结束:
- 引擎停止寻找 BEnd 事件。
- 引擎停止寻找 C 事件并停止计算每个事件。
- 引擎开始寻找 BStart 事件,因为这意味着另一个 SpanB 生命周期的开始。
在该场景中,假设 AEnd 事件到达。从逻辑上讲,这是 SpanA 生命周期的结束:
- 引擎停止寻找 AEnd 事件。
- 引擎停止寻找 BStart 事件。
- 引擎开始寻找 AStart 事件,因为这意味着另一个 SpanA 生命周期的开始。
在上面描述的场景中,在 AEnd 到达后,引擎又回到了最初创建语句后引擎的状态。
如果您的用例需要逻辑 OR 关系,例如(不等同于上述):
create context CtxSampleNestedContext
start pattern[every a=AStart or every a=BStart] as mypattern
end pattern[every AEnd or every BEnd]