In EPL, an event can be represented by any of the following underlying Java objects (NEsper .NET, see Section I.6, “.NET Event Underlying Objects”):

Sometimes an event can have properties that are itself events. EPL uses the term fragment and fragment type for such event pieces. The best example is a pattern that matches two or more events and the output event contains the matching events as fragments. In other words, output events can be a composite event that consists of further events, the fragments.

Fragments have the same metadata available as their enclosing composite events. The metadata for enclosing composite events contains information about which properties are fragments, or have a property value that can be represented as a fragment and therefore as an event itself.

Fragments and type metadata can allow your application to navigate composite events without the need for using the Java reflection API and reducing the coupling to the underlying event representation. The API is further described in Section 16.5.5, “Event and Event Type”.

More information on event representations can be found in the appendix. The links are:

sendEventBean(Object event, String eventTypeName)

sendEventMap(Map map, String mapEventTypeName)

sendEventObjectArray(Object[] objectarray, String objectArrayEventTypeName)

sendEventAvro(Object avroGenericDataDotRecord, String avroEventTypeName)

sendEventXMLDOM(org.w3c.dom.Node node, String eventTypeName)

N/A

@EventRepresentation(map)

@EventRepresentation(objectarray)

@EventRepresentation(avro)

N/A

create schema name as class_name

create map schema name as (...)

create objectarray schema name as (...)

create avro schema name as (...)

N/A

create map schema ParkingEvent as (carId string, driverName string)

insert into ParkingEvent select carId, 'jim' as driverName from CarArrivalEvent

EPL does not require a fixed tuple structure and fully supports generic tuples. Event properties can be defined, added to existing types and queried at runtime.

The facilities for support of generic tuples are:

There is no need to explicitly create an event type for each tuple type. It is not necessary to create classes for tuple types at all. Events can be arbitrary objects.

The compiler uses the type information that is available: the compiler can verifies your statement against the known properties and types, preventing you as the EPL designer from making mistakes in EPL design. The compiler does not verify dynamic properties, which may return null at runtime. If type information is not available then properties are assumed to return java.lang.Object-typed values.

For example, let's say you need a generic tuple and you have Map events:

create schema GenericTuple()

Create statements that use dynamic properties, as the next EPL shows, which casts the timestamp value to a long-type value and outputs the hour-minute-second string:

select cast(timestamp?, long).format('hh mm ss') from GenericTuple

Send events like this:

Map<String, Object> genericEvent = new HashMap<>();
genericEvent.put("timestamp", new Date().getTime());
genericEvent.put("some_other_property", "hello");
runtime.getEventService().sendEventMap(genericEvent, "GenericTuple");

The first means to handle updating events is the update istream clause as further described in Section 5.20, “Updating an Insert Stream: The Update IStream Clause”. It is useful when you need to update events as they enter a stream, before events are evaluated by any particular consuming statement to that stream.

The second means to update events is the on-merge and on-update clauses, for use with tables and named windows only, as further described in Section 6.8, “Triggered Upsert Using the On-Merge Clause” and Section 6.6, “Updating Data: The On Update Clause”. On-merge is similar to the SQL merge clause and provides what is known as an "Upsert" operation: Update existing events or if no existing event(s) are found then insert a new event, all in one atomic operation provided by a single statement. On-update can be used to update individual properties of rows held in a table or named window.

To extract information from a coarse-grained event or to perform bulk operations on the rows of the property graph in an event, EPL provides a convenient syntax: When specifying a filter expression in a pattern or in a select clause, it may contain an contained-event selection syntax, as further described in Section 5.19, “Contained-Event Selection”.

For NEsper .NET also see Section I.10, “.NET Event Objects Instantiated and Populated by Insert Into”.

The insert into clause can instantiate and populate new instances of Java object events, java.util.Map events and Object[] (object array) events directly from the results of select clause expressions. Simply use the event type name as the stream name in the insert into clause as described in Section 5.10, “Merging Streams and Continuous Insertion: The Insert Into Clause”.

If instead you have an existing instance of a Java object returned by an expression, such as a single-row function or static method invocation for example, you can transpose that expression result object to a stream. This is described further in Section 5.10.7, “Transposing an Expression Result” and Section 10.4, “Select-Clause Transpose Function”.

The column names specified in the select and insert into clause must match available writable properties in the event object to be populated (the target event type). The expression result types of any expressions in the select clause must also be compatible with the property types of the target event type.

If populating a POJO-based event type and the class provides a matching constructor, the expression result types of expressions in the select clause must be compatible with the constructor parameters in the order listed by the constructor. The insert into clause column names are not relevant in this case.

Consider the following example statement:

insert into com.mycompany.NewEmployeeEvent 
select fname as firstName, lname as lastName from HRSystemEvent

The above example specifies the fully-qualified class name of NewEmployeeEvent. The runtime instantianes NewEmployeeEvent for each result row and populates the firstName and lastName properties of each instance from the result of select clause expressions. The HRSystemEvent in the example is assumed to have lname and fname properties, and either setter-methods and a default constructor, or a matching constructor.

Note how the example uses the as-keyword to assign column names that match the property names of the NewEmployeeEvent target event. If the property names of the source and target events are the same, the as-keyword is not required.

The next example is an alternate form and specifies property names within the insert into clause instead. The example also assumes that NewEmployeeEvent has been defined or imported via configuration since it does not specify the event class package name:

insert into NewEmployeeEvent(firstName, lastName) 
select fname, lname from HRSystemEvent

Finally, this example populates HRSystemEvent events. The example populates the value of a type property where the event has the value 'NEW' and populates a new event object with the value 'HIRED', copying the fname and lname property values to the new event object:

insert into HRSystemEvent 
select fname, lname, 'HIRED' as type from HRSystemEvent(type='NEW')

The matching of the select or insert into-clause column names to target event type's property names is case-sensitive. You can specify a subset of all available columns in the target event type. Wildcard (*) is allowed and copies all fields of the events or multiple events in a join.

For Java object events, your event class must provide setter-methods according to JavaBean conventions or, alternatively, a matching constructor. If the event class provides setter methods the class should also provide a default constructor taking no parameters. If the event class provides a matching constructor there is no need for setter-methods. If your event class does not have a default constructor and setter methods, or a matching constructor, your application may configure a factory method via ConfigurationEventTypeLegacy. If your event class does not have a default constructor and there is no factory method provided, the runtime uses in connection with the Oracle JVM the sun.reflect.ReflectionFactory, noting that in this case member variables do not get initialized to assigned defaults.

The compiler follows Java standards in terms of widening, performing widening automatically in cases where widening type conversion is allowed without loss of precision, for both boxed and primitive types and including BigInteger and BigDecimal.

When inserting array-typed properties into a Java, Map-type or Object-array underlying event the event definition should declare the target property as an array.

Please note the following limitations:

Event type names of preconfigured event types are unique within both compiler and runtime.

Event type names of event types allocated by create schema are unique within both the compiler and the runtime by the combination of the deployment id and the event type name.

At runtime for internal lookups the runtime computes a CRC32 value pair. Usually you don't need to worry about CRC32 values as a collision is very unlikely and the compiler and runtime indicate relevant collisions by throwing a compile-time or deployment-time exception. For preconfigured event types the CRC32 of the type name must be unique within the runtime. For event types allocated by create schema the combination of CRC32 of the deployment id and the CRC32 of the event type name must be unique within the runtime.