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@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@gmail.com> wrote:
On 22/02/2012, Edson Tirelli <ed.tirelli@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@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@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@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@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@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/rules-users
>>>
>>>
>>
>> _______________________________________________
>> rules-users mailing list
>> rules-users@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users


_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users




--
  Edson Tirelli
  JBoss Drools Core Development
  JBoss by Red Hat @ www.jboss.com