Results 1 to 4 of 4

Thread: COMMAND mode

  1. #1
    Member
    Join Date
    Feb 2008
    Location
    Budapest
    Posts
    2

    COMMAND mode

    We are having trouble to use the setMultiMetapush function and the COMMAND mode. Can someone elaborate how this function should be used? Are there some special considerations to keep in mind when developing an adapter that would be used in COMMAND mode?

    Thank you,
    Attila

  2. #2
    Administrator
    Join Date
    Jul 2006
    Location
    Milan, Italy
    Posts
    517
    Hi Attila,

    MultiMetapush is not yet generally available. It will be publicly released with Lightstreamer Server v.3.5, due in June 2008.

    You are using a preview-release of this feature. So, considerations coming from the community will be possible only after the release of Lightstreamer Server v.3.5.

    Cheers
    Alessandro

  3. #3
    Member
    Join Date
    Feb 2008
    Location
    Budapest
    Posts
    2
    Hi Alessandro,

    I sent the question to the forum as I had no better idea who to ask.

    In regard to the COMMAND mode. Are there some special things to keep in mind when implementing a new adapter?

    Thanks
    Attila

  4. #4
    Power Member
    Join Date
    Jul 2006
    Location
    Cesano Maderno, Italy
    Posts
    784
    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:

    while probably your preview is like this:


    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.

 

 

Similar Threads

  1. command mode latency
    By Pradeep Chahal in forum Adapter APIs
    Replies: 4
    Last Post: September 3rd, 2010, 12:08 PM
  2. command mode
    By Pradeep Chahal in forum Adapter APIs
    Replies: 1
    Last Post: February 24th, 2010, 09:52 AM
  3. command mode
    By Pradeep Chahal in forum Client APIs
    Replies: 2
    Last Post: February 15th, 2010, 10:20 AM
  4. NonVisualTable with COMMAND mode
    By Alessandro in forum Client APIs
    Replies: 2
    Last Post: June 17th, 2009, 11:50 AM
  5. Sorting in command mode
    By ksivasam in forum Adapter Protocol
    Replies: 0
    Last Post: January 10th, 2008, 04:39 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
All times are GMT +1. The time now is 07:44 PM.