[This topic is pre-release documentation and is subject to change in future releases. Blank topics are included as placeholders.]
Classes
Class | Description | |
---|---|---|
![]() | PropertyCheckHelper |
Utility class for checking in a schema if fields exist and/or have an
expected type.
|
![]() | ViewEnum |
Enum for all build-in views.
|
![]() | ViewFactory |
Static factory for creating view instances based on a view specification and a given parent view.
|
![]() | ViewFieldEnum |
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.
|
![]() | ViewProcessingException |
This exception is thrown to indicate a problem with a view expression.
|
![]() | ViewServiceContext |
Contains handles to the implementation of the the scheduling service for use in view evaluation.
|
![]() | ViewServiceHelper |
Utility methods to deal with chains of views, and for merge/group-by views.
|
![]() | ViewServiceImpl |
Implementation of the view evaluation service business interface.
|
![]() | ViewServiceProvider |
Static factory for implementations of the net.esper.view.ViewService interface.
|
![]() | ViewSpec |
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.
|
![]() | ViewSupport |
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. |
![]() | ZeroDepthStream |
Event stream implementation that does not keep any window by itself of the events
coming into the stream.
|
Interfaces
Interface | Description | |
---|---|---|
![]() | ContextAwareView | Views use this interface to indicate that the view requires services out of the context,
such as the scheduling service.
|
![]() | EventCollection | 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.
|
![]() | EventStream |
A streams is a conduct for incoming events. Incoming data is placed into streams for consumption by queries.
|
![]() | HistoricalEventViewable |
Interface for views that poll data based on information from other streams.
|
![]() | ParentAwareView |
Interface for use by views to indicate that the view must couple to parent views.
|
![]() | ValidatedView | Interface for views that require validation against stream event types. |
![]() | View | 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.
|
![]() | Viewable | 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.
|
![]() | ViewService | Service interface for creating views. |