[rules-dev] Fwd: Window syntax extensions

Resending... ---------- Forwarded message ---------- Karen and Matthias, Thanks for the suggestions. A few items that we need to solve before we decide on a syntax: 1. The qualification of the units: we need to be able (as a CEP engine) to allow the definition of arbitrary time windows, like seconds, minutes or hours or compositions of them. So, a few notations could be used: 30 sec, 30 min, 30 hours (or variations of that), 25:10:23 (25 hours and 10 minutes and 23 seconds), etc. I would really like to avoid hard coding the unit parsing in the DRL parser, since the parser is one of the more delicate pieces of the code to change. We can avoid that if we use delimiters to declare the "parameters" of the window, as the parser can simply read it all as a String chunk and let each window handler deal with its own units. So, the suggestion is to use () or something like that to provide the parameters to the window handlers, in a way like that: window:time( 30 min ) or time-window( 30 min ) or another variation of that window:events( 60 ) or events-window( 60 ) or another variation of that 2. The smallest "unit" in a rule definition is a Pattern, and right now, a Pattern looks like this: [<var-bind> : ] <Pattern-Type>( [<constraints>] ) [from <source>] <> : means must be replaced by the corresponding data [] : means optional Now, what we need is a way to declare window constraints for patterns. The accumulate example I gave you was not a good one, because accumulates have 2 or more patterns (the inner patterns and the accumulate result pattern). You can even apply different window constraints for each of the patterns. So, thinking about a single pattern, how would you define a window for it? Given the current grammar and the concept of pattern, I see only two options: either we define the window constraints inside the pattern declaration ( i.e., near regular constraints), or we create another keyword to introduce them (like we have the "from" keyword). option 1: [<var-bind> : ] <Pattern-Type>( [<window-constraints> ,] [<constraints>] ) [from <source>] option 2: [<var-bind> : ] <Pattern-Type>( [<constraints>] ) [from <source>] [with <window-constraints>] Note: replace the "with" above with the keyword we chose. Just as a real world example, if you look at ESPER queries, they do events correlation like this: select * from TxnEventA.win:time(30 minutes) A join TxnEventC.win:time(60 minutes) C on A.transactionId = C.transactionId join TxnEventB.win:time(30 minutes) B on B.transactionId = C.transactionId where C.transactionId is null One example of event aggregation is this: select min(latencyAC) as minLatencyAC, max(latencyAC) as maxLatencyAC, avg(latencyAC) as avgLatencyAC from CombinedEvent.win:time (30 minutes) So, you see that the time windows are defined for each pattern and they may be different among joined patterns. Accumulate may have multiple inner patterns, and so, we need to be able to define windows for each one. On our initial suggestions, we would define the window constraints inside the pattern, as this is a lot better to avoid grammar ambiguities. The use of square brackets would help to avoid the need of creating new keywords, but as long as we decide that it is worth to create at least one keyword (like "window" for instance), we can avoid the []: TemperatureReading( window:time(30 sec), temp > 50 ) from streamA TemperatureReading( window:events(60), window:time(1 min), temp > 50 ) from streamB Something closer to what you suggested would be (replace "with" with a chosen keyword) : TemperatureReading( temp > 50 ) from streamB with window:events(60), window:time(1 min) My preference is to keep that inside the pattern, but would like to hear from you (if the change proposed in item #1 is ok) and from Mark and Michael. 3. Regarding "distinct", "group by" and "order by", we want to support that, specially "distinct". From a syntax perspective, I would like to use a similar solution as we chose for the windows, so that we can keep the language easier to learn, but if it is best for clarity to use them like "distinct PatternA(...)", I'm ok with that too. Unfortunately, we can't allow distinct directly for attributes, as different from SQL, we need to declare all the patterns that make a tuple. So, instead of saying something like: Person( distinct address ) we need to say something like: distinct Address() from $person.address Address( distinct ) from $person.address Anyway, item #3 is of minor importance right now. Sorry for the long e-mail. Edson 2007/11/27, kw14(a)mail.inf.tu-dresden.de <kw14(a)mail.inf.tu-dresden.de&gt;: -- Edson Tirelli JBoss Drools Core Development Office: +55 11 3529-6000 Mobile: +55 11 9287-5646 JBoss, a division of Red Hat @ www.jboss.com -- Edson Tirelli JBoss Drools Core Development Office: +55 11 3529-6000 Mobile: +55 11 9287-5646 JBoss, a division of Red Hat @ www.jboss.com