[
https://issues.jboss.org/browse/JBRULES-3514?page=com.atlassian.jira.plug...
]
Edson Tirelli edited comment on JBRULES-3514 at 5/23/12 1:08 PM:
-----------------------------------------------------------------
* *(WL8)* : *(a)* Lol! My wording in there might be bad, but if the user wrote "any
A()", then he does not care about which A the engine picks as long as it picks one.
:) It is like conflict resolution in rule activations where all the used conflict
resolution strategies are "tied" for a set of activations... it shouldn't
matter which one the engine picks first, since the user defined it that way. If the user
requires a specific event to be considered, then he should write his rules as so using
other qualifiers. *(b)* I clarified that the current implementation of "any"
will pick the first event that matches the pattern. Regarding why only 2 results, it is
because of the semantics of every(): once the first match is found ([A1,C1]), every
instructs the engine to look for a new match, and according to the sequence of events in
our sample stream, the next A event after the match is complete on C1 is A4, followed by
C3, resulting in the second match of [A4,C3]. Please note that it all depends on how the
qualifiers are used. E.g., if the user would write "every A() -> any C()"
then "every" would apply to "A()" only and not the whole expression
(please note the lack of parenthesis). In this case, it would start a new match for every
A() instead of only starting a new match after the first match is completed.
* *(WL9)* : I agree with you that consuming events is probably the most common use case,
but it is not the only one. I added the "retract" syntax to the proposed
"event" construct and I also added a note to consider adding the
"next" keyword as well as it is very compact.
* *(WL10)* : Lol, I changed the "insert into" syntax to go before the definition
as you proposed. The problem with "from" is that it is ambiguous to use in the
way you propose. If we use a different keyword, it would be possible to write it at the
end of the construct. Will think about this a bit more.
* *(WL11)* : (a) yes, this is being addressed under a different work, but you raise a good
point as a delimiter might be required after all. Let me think a bit more about it. (b) it
is possible to add a window to the first event in a sequence, it is just redundant... it
is like in a traditional rule in Drools 5.4, writing "X() over window:...(...)"
without wrapping that into a complex CE like an accumulate... all X events will match
because the clock is assumed to be sychronized and all X events will then be in the window
scope at the time they are inserted.
Thanks for all the valuable comments and contributions so far. Let me know if I missed
something.
was (Author: tirelli):
* *(WL8)* : *(a)* Lol! My wording in there might be bad, but if they user wrote
"any A()", then he does not care about which A the engine picks as long as it
picks one. :) It is like conflict resolution in rule activations where all the used
conflict resolution strategies are "tied" for a set of activations... it
shouldn't matter which one the engine picks first, since the user defined it that way.
If the user requires a specific event to be considered, then he should write his rules as
so using other qualifiers. *(b)* I clarified that the current implementation of
"any" will pick the first event that matches the pattern. Regarding why only 2
results, it is because of the semantics of every(): once the first match is found
([A1,C1]), every instructs the engine to look for a new match, and according to the
sequence of events in our sample stream, the next A event after the match is complete on
C1 is A4, followed by C3, resulting in the second match of [A4,C3]. Please note that it
all depends on how the qualifiers are used. E.g., if they user would write "every A()
-> any C()" the every would apply to A() only and not the whole expression (please
note the lack of parenthesis). In that case, it would start a new match for every A()
instead of only starting a new match after the first match is completed.
* *(WL9)* : I agree with you that consuming events is probably the most common use case,
but it is not the only one. I added the "retract" syntax to the proposed
"event" construct and I also added a note to consider adding the
"next" keyword as well as it is very compact.
* *(WL10)* : Lol, I changed the "insert into" syntax to go before the definition
as you proposed. The problem with "from" is that it is ambiguous to use in the
way you propose. If we use a different keyword, it would be possible to write it at the
end of the construct. Will think about this a bit more.
* *(WL11)* : (a) yes, this is being addressed under a different work, but you raise a good
point as a delimiter might be required after all. Let me think a bit more about it. (b) it
is possible to add a window to the first event in a sequence, it is just redundant... it
is like in a traditional rule in Drools 5.4, writing "X() over window:...(...)"
without wrapping that into a complex CE like an accumulate... all X events will match
because the clock is assumed to be sychronized and all X events will then be in the window
scope at the time they are inserted.
Thanks for all the valuable comments and contributions so far. Let me know if I missed
something.
Add support to event sequencing
-------------------------------
Key: JBRULES-3514
URL:
https://issues.jboss.org/browse/JBRULES-3514
Project: Drools
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: drools-api, drools-compiler, drools-core
Reporter: Edson Tirelli
Assignee: Edson Tirelli
Fix For: 5.5.0.Beta1
The purpose of this ticket is to centralize the discussions regarding the implementation
of event sequencing as detailed in the wiki page at:
https://community.jboss.org/wiki/EventSequencing
The highlevel discussions can be added to this ticket while individual sub-tickets will
be created for the implementation of each sub-feature.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see:
http://www.atlassian.com/software/jira