Hi,
this is the beta-documentation of such method:
/**
* 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
*/
Note that this method will be:
[syntax="JS"]setMultiMetapush(underlyingSchema:*, underlyingDataAdapter:String = ""):void[/syntax]
while probably your preview is like this:
[syntax="JS"]setMultiMetapush(underlyingSchema:*, underlyingMode:String = "MERGE", underlyingDataAdapter:String = ""):void[/syntax]
Moreover in the preview release conflicted fields were not handled with the $ character.
About the adapter I assume you're asking about consideration to take in account for such multimetapush. The only thing you should assure is that the key values of the COMMAND item are equals to the item names of the associated MERGE items.
HTH.
