/**
* Only effective if "COMMAND logic" behaviour has been configured
* in setKeyPolicy(). It enables a two-level extension of this behaviour,
* in which the values for each row are provided:
* <ul>
* <li>in part through the ADD and UPDATE commands;</li>
* <li>in part through a second-level, or "underlying" item, determined by
* the row key, which defines an implicit row-like data table, automatically
* created and managed according to the row lifecycle.</li>
* </ul>
* In synthesis, each time a new row is created, an underlying data table is also created
* and subscribed automatically to feed fields not handled by the first-level
* updates. This table is a mono-item table, where the item name that is used
* is the key value associated to the row. The item is subscribed to in
* "MERGE" mode, with snapshot request and with the same maximum frequency
* setting as for the first-level items (including the "unfiltered" case).
* All other subscription properties are left as the default.
* When the row is deleted, the underlying data table is also removed.
* <BR>We call this a "MultiMetapush logic" behaviour.
*
* @param underlyingSchema An Array of field names or a String schema identifier,
* which identifies the fields provided by the second-level items.
* In the first case, a LiteralBasedProvider or equivalent Metadata Adapter is needed
* on the Server in order to understand the subscription request.
* <BR>If field names are specified, fields can be accessed by name
* during event dispatching and, if associated with a control field,
* names should be used to pair field and "column". The second-level
* field names should better be different from the first-level field
* names, so that no name conflict can arise. In case of name conflicts,
* a "$" character must be preponed to the second-level field name.
* <BR>On the contrary, if group name is specified, the pairing
* should be done with field indexes. In this case, the field
* position indexes to be used should start from the highest position of
* the first-level schema + 1.
* <BR>Note that the first-level and second-level schemas must be declared
* in the same way, i.e. both through an Array of field names of both
* through a schema identifier.
*
* @param underlyingDataAdapter the name of a Data Adapter (within the
* Adapter Set used by the current session), which identifies the
* underlying Data Adapter, which supplies all the second-level items;
* the parameter is optional and the default is the "DEFAULT" name. All the possible second-level
* items should be supplied in "MERGE" mode with snapshot available.
* <BR>The Data Adapter name is configured on the server side through
* the "name" attribute of the "data_provider" element, in the
* "adapters.xml" file that defines the Adapter Set (a missing attribute
* configures the "DEFAULT" name).
*
* @see #setKeyPolicy
*/
Bookmarks