current_timestamp() cached results at WHERE clause. Is this the expected behavior?

Question

At Esper online (8.5 - https://esper-epl-tryout.appspot.com/epltryout/mainform.html) It seems that current_timestamp() single row method is acting as a cached one when it is present at WHERE section. I don’t remember this behavior before (I think it reevaluates with each event).

i.e given:

create schema iotEvent(id string, type string, value double);

SELECT current_timestamp().getSecondOfMinute()%2 as zeroorone 
FROM iotEvent 
WHERE current_timestamp().getSecondOfMinute()%2=0

and the following event flow:

iotEvent={id='A', type="pump", value=1.0}
t=t.plus(1 sec)
iotEvent={id='B', type="dump", value=12.0}
t=t.plus(1 sec)
iotEvent={id='C', type="pump", value=4.0}
t=t.plus(1 sec)
iotEvent={id='A', type="dump", value=15.0}
t=t.plus(1 sec)
iotEvent={id='B', type="pump", value=2.0}
t=t.plus(1 sec)
iotEvent={id='A', type="dump", value=3.0}

"zeroorone" at select list iterate values 0,1,0,1,... as expected but the where expression just takes 0 or 1 depending on the initial event result. In this case 0 (so it matches all the time).

On the other hand:

SELECT current_timestamp().getSecondOfMinute()%2 as zeroorone 
    FROM iotEvent 
    WHERE current_timestamp().getSecondOfMinute()%2=1

Never matches.

We don’t see this behavior in our Esper deployments (v 7). Has anything changed in 8.5 single row methods cache policies?, is this the desired behavior?

Thanks!

Answer 1

This is probably a bug due to the more agressive filter index planning. The doc link is Compiler Filter Expression Analysis. This can be disabled in the compiler settings.