Techniques for Two-Tier Tables
The
IliTable class also provides a set of member functions dedicated to managing two-tier tables. A two-tier table is tied to rows that are managed by some external process or system; therefore serving as a bridge between Data Access and this external system. For instance, the
IliSQLTable class (described in
Hints and Tips for Using Data Access) serves as a bridge to relational database systems. The
DirectoryTable sample class serves as a bridge to the file system. See
Subclassing Example.
A two-tier table is usually defined by specifying some sort of criteria that will be used to identify a result set extracted from the remote or external system. Precisely how this is done depends on the subclass of
IliTable being used. For an
IliSQLTable, for example, an SQL SELECT statement has to be specified.
The IliTable::select member function retrieves the data from the external system identified by the above mentioned criteria. This data is then copied into a local row cache managed by the table object.
With a two-tier table, the basic row management member functions (described in section
Managing Rows in a Table) perform specific actions, the details of which depend on the specific subclass being used. For more information, refer to the appropriate class in the Rogue Wave Views
Data Access Reference Manual.
A two-tier table can retrieve rows in one of the following ways:
The
select member function immediately retrieves all rows identified by the selection criteria and stores them in the local row cache.
The
select member function locates the rows identified by the selection criteria in the external system, but delays their retrieval until they are required.
The
getRowsCount member function returns the number of rows that are located in the local row cache. However, when a two-tier table implements the delayed row retrieval, the value returned by
getRowsCount corresponds to the number of rows that have been retrieved to date. It does not take into account those rows that have not been retrieved yet.
The IliTable::fetchCompleted member function returns true when all rows have been retrieved and stored in the local row cache. This member function can therefore be used to check that the row count (as returned by getRowsCount) is definitive.
The IliTable::fetchNext and IliTable::fetchAll functions are used to retrieve explicitly a fixed number of rows or all remaining rows from the result set. However, when any of the insertRow, updateRow, deleteRow, and getValue member functions are called and given a row number outside of the rows in the local row cache, all missing rows up to this row are retrieved. In this way, the delayed retrieval feature is transparent except for the rows count.
The insertRowInCache, updateRowInCache, and deleteRowInCache member functions are similar to their non-inCache counterparts except that they simply act on the local row cache, leaving the remote data store unaffected.
The
IliTable::clearRows clears the row cache. For two-tier tables, the external system to which the
IliTable object is tied is not affected by the
clearRows member function. A subsequent select would retrieve the same rows again.
In a one-tier table, however, the
IliTable::clearRows effectively deletes all rows in the
IliTable object.
Version 6.1
Copyright © 2016, Rogue Wave Software, Inc. All Rights Reserved.