Working With Sliding Tumbling and Time Windows
Sliding, tumbling, and time windows are explicit windows. In an explicit window, the lifecycle of an entity in a window is determined either by a specified duration of the entity in the window, or by setting a maximum number of entities that can be in the window at any time.
The stream policy (also known as a window policy) determines what kind of lifecycle and what kind of window to use: a time window, sliding window, or tumbling window.
You can filter entities entering the query using a where in the stream policy. You can also do aggregations within the window using a by clause. See Stream Policy.
Use Explicit Windows for Events and not Concepts
Concepts are mutable. Events are immutable after they are asserted. The mutability of concepts makes them generally unsuitable for cache queries that use sliding, tumbling, or time windows, as explained next.
Entities enter a sliding, tumbling, or time window when they are added to the cache and they remain in the window according to criteria such as duration in the window or number of items in the window. This characteristic enables you to gather statistical information such as how many transactions were processed in an hour.
Deleting an entity from the cache does not cause it to be removed from such a window. (This behavior is different from the behavior of implicit windows.)
When a concept is modified, internal actions delete the old value from the cache and add the new one. Sliding, tumbling, and time windows ignore the deletion, but recognize the addition. Therefore the old and the new value both appear in the window, leading to unexpected results.
Events are immutable (after assertion), so this issue does not arise in the case of events.
- Explicit Window Example (Cache Query)
In SQL, the order in which the clauses are presented in a query string is not the order in which they are processed.