RowMatch is used to apply in-memory a qualifying expression to rows in memory. The user specifies a SQL expression.
A RowMatch may be used stand-alone or used a qualifying RowMatch for a ViewObject. To use it stand-alone, one would create a RowMatch. Then, to see if a Row qualifies, one would invoke rowQualifies(Row). Here is an example:
RowMatch rowMatch = new RowMatch("Deptno = 30");
if (rowMatch.rowQualifies(row))
{
System.out.println("We have a row whose Deptno is 30");
}
To use a RowMatch for a ViewObject, invoke ViewObject.setRowMatch(RowMatch). Rows will be qualified in-memory.
RowMatch differs from the where-clause of a database query statement mainly in that one should use row's attribute names as opposed to the database column names. Note that database column names are by default case-insensitive, while attribute names are case-sensitive.
Where-clause qualfication only applies to rows already exsiting in the database table. RowMatch will apply to rows as they are read from database query as well. Additionally, RowMatch is applied to rows that are created because of view link consistency.
View link consistency allows a RowSet to see new rows (unposted) created by another RowSet. Internally, when a new row is created by the other RowSet and the row's primary key is set, the original RowSet (if view link cosnsistency is on) receives an event indicating a new row has been created. This RowSet creates a row and inserts it in its collection. Before this copy row is inserted, it is tested against the view object's RowMatch. Only if the row qualifies will it be inserted.
If a qualification can be expressed in a query's where-clause, one should use the where-clause, because database will skip unqualifying rows. If one relies solely on the RowMatch for in-memory qualification, he may incur unnecessary performance overhead, because rows will be read from database query and formed in memory.
Unlike a where-clause, a RowMatch can evaluate expression involving transient attributes and not-yet-posted attribute values.
A RowMatch may be used stand-alone or used a qualifying RowMatch for a ViewObject. To use it stand-alone, one would create a RowMatch. Then, to see if a Row qualifies, one would invoke rowQualifies(Row). Here is an example:
RowMatch rowMatch = new RowMatch("Deptno = 30");
if (rowMatch.rowQualifies(row))
{
System.out.println("We have a row whose Deptno is 30");
}
To use a RowMatch for a ViewObject, invoke ViewObject.setRowMatch(RowMatch). Rows will be qualified in-memory.
RowMatch differs from the where-clause of a database query statement mainly in that one should use row's attribute names as opposed to the database column names. Note that database column names are by default case-insensitive, while attribute names are case-sensitive.
Where-clause qualfication only applies to rows already exsiting in the database table. RowMatch will apply to rows as they are read from database query as well. Additionally, RowMatch is applied to rows that are created because of view link consistency.
View link consistency allows a RowSet to see new rows (unposted) created by another RowSet. Internally, when a new row is created by the other RowSet and the row's primary key is set, the original RowSet (if view link cosnsistency is on) receives an event indicating a new row has been created. This RowSet creates a row and inserts it in its collection. Before this copy row is inserted, it is tested against the view object's RowMatch. Only if the row qualifies will it be inserted.
If a qualification can be expressed in a query's where-clause, one should use the where-clause, because database will skip unqualifying rows. If one relies solely on the RowMatch for in-memory qualification, he may incur unnecessary performance overhead, because rows will be read from database query and formed in memory.
Unlike a where-clause, a RowMatch can evaluate expression involving transient attributes and not-yet-posted attribute values.
