Iterating over the rows in a table
Iterators have operations to step through the table and determine when the end has been reached. Provided an iterator is not at the table’s end, the key it is at can be obtained.
Iterator events define actions that do the following:
Step through the rows in a table.
Determine when the last row has been reached.
Obtain the key of the row that the iterator is at. The iterator must not be at the end of the table for this action to be successful.
Obtain a
Row event to represent the row that the iterator is at.
The following sample code reads table content:
Iterator i := begin();
while not i.done() {
Row row := i.getRow();
if row.inTable() then {
// Put code here to read the row in the way you want.
}
i.step();
}
The following sample code modifies table content:
Iterator i := begin();
while not i.done() {
Row row := i.getRow();
boolean done := false;
while row.inTable() and not done {
// Put code here to modify the row in the way you want.
done := row.tryCommitOrUpdate();
}
i.step();
}
Iterating through a table is always safe, regardless of what other threads are doing. However, if another context adds or removes a row while you are iterating in your context, it is undefined whether your iterator will see that row.
Furthermore, it is possible for another context to remove a row while your iterator is pointing at it. If this happens, a subsequent Iterator.getRow() returns a Row event that represents a row for which Row.inTable() is false.
If an EPL action loops, the correlator cannot perform garbage collection within that loop. (See
Optimizing EPL programs.) Performing intricate manipulations on many rows of a large table could therefore create so many transitory objects that the correlator runs out of memory. If this becomes a problem, you can divide very large tasks into smaller pieces, each of which is performed in response to a routed event. This gives the correlator an opportunity to collect garbage between delivering successive events.