Syntax Element | Description |
event_type | Name of the event type that you want to operate on. The event type must be parsable. See
Type properties summary. Event type names can come from the root namespace, a using declaration, or a local package as specified in a package declaration. |
event_filter | Optionally filter which events of this type you want to be in the window. For example, you might define the window to contain only the events whose amount field is greater than 10. The rules for what you can specify for the event filter are the same as for what you can specify in an event template in EPL. See
Event templates. |
query_key | Specify one or more event fields or actions. You can specify event fields of type boolean, decimal, float, integer, string or location. When an action is used as an input key, an alias must be supplied. The correlator uses the key to partition the events. Each partition is identified by a unique key value. One or two keys is typical. Three is unusual and rarely needed. More than three key values is discouraged. When you define more than one input in a query The number, type, and order of the key fields in each input definition must be the same. If the names of the key fields are not the same in each input definition, you must specify aliases so that the names match. For details, see
Partitioning queries. |
retain_clause | Optionally specify retain followed by an EPL integer expression that indicates how many events to hold in the window. For example, if you specify retain 1, only the last event that arrived that is of the specified type and that has the key value(s) associated with that partition is in the window. You must specify a retain clause or a within clause or both. While it is possible to retain any number of events, you must ensure that you define an input that allows a match with the event pattern specified in the corresponding find statement. For example, the following query never finds a match: query Q { inputs { A() key k retain 3; } find A as a1 -> A as a2 -> A as a3 -> A as a4 { print a1.toString()+ " - "+a4.toString(); } } |
within_clause | Optionally specify within followed by a float expression or time literal that specifies the length of time that an event remains in the window. You must specify a retain clause or a within clause or both. See
Specifying event duration in windows. |
with_unique_clause | Optionally specify a set of secondary keys which constrains the window to only include the latest event for each value for the set of keys. See
Matching only the latest event for a given field. |
time_from_clause | Optionally specify time from followed by the name of an action that specifies how the source timestamp of the event can be obtained. The named action must be an action defined on that input event type. It must take no parameters and must return a float. This is taken to be when the event occurred, specified as seconds since the epoch. Note: You are not permitted to use the event's built-in getTime() method. This method returns the time when the correlator either processed or created the event, which defeats the purpose of the source timestamp functionality. |
wait_clause | If a time_from_clause is provided, a wait_clause is required, which specifies wait followed by a float expression or time literal which specifies the maximum delay expected for events. This is how long a query will wait for events if it has not received any events. See also
Using heartbeat events with source timestamps and
Out of order events. |
or_clause | Optionally specify a heartbeat event type which informs the query runtime when communication with the data source is not delayed. See
Using heartbeat events with source timestamps. This can only be specified if the time_from_clause and wait_clause are specified. |