One of the focus areas for us in V1.2 was the LINQ surface of StreamInsight. We have straightened out many of the kinks people complained about in previous versions and have added new features. Too many improvements for a single blog post, so today we’ll start with new features in the event type system.
One of the big limitations in StreamInsight so far was the requirement to express event types as a “flat” list of fields. What we are introducing with our current version is the ability to use nested structures as event types. You can now use fields that are instances of another class or struct, and you can define such nestings with arbitrary depth. Let’s look at an example:
Here, we are planning to use Vehicle as our event type, with a field of type Location. We can create our payloads in the input adapter (or as a .NET sequence item) as expected:
Within LINQ query statements, you can refer to these nested fields:
(We are assuming that these two input streams actually contain overlapping events, otherwise the join wouldn’t produce anything.)
Now we’d like to clarify a few things here:
How do you deal with nested fields in untyped adapters? Well, no change here. You still use the GetField/SetField methods of the event, passing the ordinal of the desired field. You get the ordinal for a field from its name through the CepEventType dictionary. The name for a nested field is for example Loc.X, just like in a programmatic reference.
Attached is a LINQPad sample that demonstrates nested types – you will also find it as part of the samples that come with the plugin. The sample also uses a macro for a common streaming design pattern, more about that in a later post. Don’t forget to update the plugin, btw!
Regards, The StreamInsight Team
Hello!
1. How long evaluation trial period for StreamInsight use?
2. Now I use StreamInsight 1.1. If I start to use StreamInsight 1.2, my trial period start over again for 1.2?
The trial period is 180 days and starts over if you install 1.2.