A couple comments:
* The temporal reasoning features/operators are available in both CLOUD and
STREAM mode. The biggest differences are that in CLOUD mode there is no
automatic garbage collection of old events and you can't use sliding
windows, but everything else works.
* You can insert events with old timestamps, but in that case it is the
rule's author responsibility to understand that sliding windows using that
event type might be affected and if running in STREAM mode, you should
define an expiration policy for that event type that will keep him in
memory for enough time to match any rules that require it. For instance, if
in your application events will have a maximum duration of 24hs and because
of that they can be inserted into the system with a delay of 24hs, you
should define an expiration policy for it that is at least 24hs.
Edson
2012/2/24 Matteo Cusmai <cusmaimatteo(a)gmail.com>
Hi Wolfgang,
thanks a lot for the explanation, but i am very sad now.
I have to use STREAM mode, because i am implementing a spatio-temporal
expert system, so, i need of temporal reasoning. I need to compare events
on time too.
>From my understaning, i am limitated by:
- i cannot update timestamp and duration of an event;
- i cannot insert a new event with an old timestamp
is it right?
In a realtime sensor system, i don't receive the event with duration, but
i need to correlate them to have an event with duration.
Do you have any suggestions?
Thanks a lot,
Matteo.
On Thu, Feb 23, 2012 at 7:39 AM, Wolfgang Laun <wolfgang.laun(a)gmail.com>wrote:
> On 22/02/2012, Edson Tirelli <ed.tirelli(a)gmail.com> wrote:
> > If your use case somehow has "mutable" events, you can retract,
> change
> > the duration and reinsert.
>
> But mind the requirements of STREAM mode: Events in each stream must
> be time-ordered. I.e., inside a given stream, events that happened
> first must be inserted first into the engine. If reinsertions would
> violate this, you must run the session in CLOUD mode, which has
> certain consequences. This is all very well described in the Fusion
> manual, section on "Event Processing Modes".
>
> -W
>
>
> > The engine uses optimizations for the temporal
> > reasoning that are based on the fact that events should be immutable.
> That
> > is why the engine "resolves" the timestamp/duration attributes at
insert
> > time and make them immutable.
> >
> > Edson
> >
> > 2012/2/22 Matteo Cusmai <cusmaimatteo(a)gmail.com>
> >
> >> Hi Edson,
> >> so, when i want modify an event, i could do as follow:
> >>
> >> - clone event;
> >> - change the duration
> >> - retract the previuos event
> >> - insert the new event
> >>
> >> Is it right?
> >>
> >> Bye bye,
> >>
> >> Matteo.
> >>
> >> 2012/2/22 Edson Tirelli <ed.tirelli(a)gmail.com>
> >>
> >>>
> >>> Unfortunately you can't update event durations or timestamp.
Events
> >>> are supposed to represent things that happened and as so, are
> immutable
> >>> (other than data enrichment). If an event representation is no longer
> >>> true,
> >>> that event has to be retracted. Most common case is when you are
> dealing
> >>> with atomic events (like start and end atomic events) that represent a
> >>> complex event. Usually you will have a rule that correlates the start
> and
> >>> end atomic events and creates a complex derived event, retracting the
> >>> atomic ones.
> >>>
> >>> Edson
> >>>
> >>> 2012/2/22 Matteo Cusmai <cusmaimatteo(a)gmail.com>
> >>>
> >>>>
> >>>> Hi all,
> >>>> i am using Drools Fusion in multi sensor data fusion system. I have
> some
> >>>> rules that generate a new event when some situations occur. But
from
> the
> >>>> other hand, i would like to update the event, when i understand
that
> new
> >>>> sensor observation is referring to the same event. I have my Event
> clazz
> >>>> with duration field, i try to update it in modify clause, but i
have
> >>>> concern about it, because when i use temporal operator (such as
> before,
> >>>> meets, so on) it seems that Drools manage them as event with
duration
> >>>> null.
> >>>> I could post the code too.
> >>>> Bye bye,
> >>>> Matteo.
> >>>> _______________________________________________
> >>>> rules-users mailing list
> >>>> rules-users(a)lists.jboss.org
> >>>>
https://lists.jboss.org/mailman/listinfo/rules-users
> >>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> Edson Tirelli
> >>> JBoss Drools Core Development
> >>> JBoss by Red Hat @
www.jboss.com
> >>>
> >>> _______________________________________________
> >>> rules-users mailing list
> >>> rules-users(a)lists.jboss.org
> >>>
https://lists.jboss.org/mailman/listinfo/rules-users
> >>>
> >>>
> >>
> >> _______________________________________________
> >> rules-users mailing list
> >> rules-users(a)lists.jboss.org
> >>
https://lists.jboss.org/mailman/listinfo/rules-users
> >>
> >>
> >
> >
> > --
> > Edson Tirelli
> > JBoss Drools Core Development
> > JBoss by Red Hat @
www.jboss.com
> >
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/rules-users
>
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users