[This topic is pre-release documentation and is subject to change in future releases. Blank topics are included as placeholders.]

Classes

  ClassDescription
public classPropertyCheckHelper
Utility class for checking in a schema if fields exist and/or have an expected type.

public classViewEnum
Enum for all build-in views.

public classViewFactory
Static factory for creating view instances based on a view specification and a given parent view.

public classViewFieldEnum
Enumerates the valid values for each view's public fields. The name of the field or property can be used to obtain values from the view rather than using the hardcoded String value for the field.

public classViewProcessingException
This exception is thrown to indicate a problem with a view expression.

public classViewServiceContext
Contains handles to the implementation of the the scheduling service for use in view evaluation.

public classViewServiceHelper
Utility methods to deal with chains of views, and for merge/group-by views.

public classViewServiceImpl
Implementation of the view evaluation service business interface.

public classViewServiceProvider
Static factory for implementations of the net.esper.view.ViewService interface.

public classViewSpec
Encapsulates the information required to specify a object construction. A object construction specification can be equal to another specification. This information is important to determine reuse of any object.

public classViewSupport
A helper class for View implementations that provides generic implementation for some of the methods. Methods that contain the actual logic of the view are not implemented in this class. A common implementation normally does not need to override any of the methods implemented here, their implementation is generic and should suffice.

The class provides a convenience method for updateing it's children data UpdateChildren(Object[], Object[]). This method should be called from within the View.update(Object[], Object[]) methods in the subclasses.


public classZeroDepthStream
Event stream implementation that does not keep any window by itself of the events coming into the stream.

Interfaces

  InterfaceDescription
public interfaceContextAwareView
Views use this interface to indicate that the view requires services out of the context, such as the scheduling service.

public interfaceEventCollection
Interface that marks an event collection. Every event in the event collection must be of the same event type, as defined by the getEventType() call.

public interfaceEventStream
A streams is a conduct for incoming events. Incoming data is placed into streams for consumption by queries.

public interfaceHistoricalEventViewable
Interface for views that poll data based on information from other streams.

public interfaceParentAwareView
Interface for use by views to indicate that the view must couple to parent views.

public interfaceValidatedView
Interface for views that require validation against stream event types.

public interfaceView
The View interface provides a way for a stream, data provider, or another view, to notify an object of additions and deletions to its data set. Views are themselves Viewable by other Views, and can implement their own set of cached data internally. The contract is that a View is wholly derived from the object (its parent) to which it is attached. That is, it must be able to reconstitute its cached state from a playback of source data passed to it through the update() method. A view's job is to derive some data from the data in the Viewable object to which it is attached. This can happen by a 'push' mechanism whereby new data in the underlying collection is pushed to the view through the update method. A view that operates in this mode incrementally updates its derived data and then provides this data to any queries or requesters through its Data interface and potentially through other customized methods it exposes. When these methods are called, the view in push mode does not contact its parent: it just supplies the requester with the data it already derived. The push mode is efficient when data in a view is slow-changing with respect to how much its data is requested. For example, a view calculating the mean of an intermittent signal over time may be queried very frequently. It incrementally updates its statistic and then provides that quantity to callers whenever they want it, which may be much more frequently than the incoming signal occurs. The 'pull' mechanism is driven by requests to the view's Data interface or other customized data access methods. A view operating in 'pull' mode may know whether it is "clean" or "dirty" by listening to its update method, or it may not get any calls to its update method, and have to consult its parent to re-derive data when it is called. This mode is efficient when requests to a view for its data are infrequent compared to the update frequency of its parent's data. For example, a temperature sensor may be changing on a near-continuous basis, and a view which derives some quantity from that sensor may be queried irregularly. It is most efficient for that view to operate in pull mode, and only update itself when it is asked by some consumer for its derived quantity. It then asks the temperature sensor for the current temperature, does its derivation, and returns to the requester. To feed views that are registered with it, a view should only call the update method on its child views when its own data has changed. If it receives an update which results in no change to its data, it should not update any children views.

public interfaceViewable
The Viewable interface marks an object as supporting zero, one or more View instances. All implementing classes must call each view's 'update' method when new data enters it. Implementations must take care to synchronize methods of this interface with other methods such that data flow is threadsafe.

public interfaceViewService
Service interface for creating views.