Subscribing to the Table

To subscribe to the table "Table 1" we are calling LSClient.SubscribeTable() passing ExtendedTableInfo. Constructor of ExtendedTableInfo does not accept table name, it accepts an array of item names. If we pass an array with one item and put a table name into it we can get all the items in the table. Is this the right thing to do (the constructor of ExtendedTableInfo is accepting a list of table names) or is the picture in page 5 of General Concepts.pdf is incorrect? In any case why does ExtendedTableInfo constructor accept an array of items?

With reference to the picture in General Concepts.pdf, a data table is characterized by a list of Item names or, alternatively, by a "Group" name.
The two alternatives are reflected by the overloads of LSClient.SubscribeTable():

• If you supply a SimpleTableInfo instance, you are describing the table through a Group name; the Metadata Adapter will expand the name into a list of items in getItems.
• If you supply an ExtendedTableInfo instance, you are describing the table through a list of Item names; the Metadata Adapter will still receive a call to getItems and in this case it will receive the space-separated join of the Item names and it will be supposed to extract the Item names from the bundle, as the LiteralBasedProvider does.

Note that the name of the data table ("Table1" in the picture) is not used by the Server, hence LSClient.SubscribeTable() does not require you to specify one.

Your claim that

Quote:

---

If we pass an array with one item and put a table name into it we can get all the items in the table

---

does not fit into the above description and should be clarified.

Thank you for the prompt response.

In our case we need to subscribe to the whole table. We don't know the list of items at the time of subscription. We are subsribing in a COMMAND mode and are expecting to receive a snapshot i.e. a list of items.
Should we use the SimpleTableInfo for this?
Does a group always contain all items in a table, or can it be a subset?

Presumably, in the method OnUpdate from an IHandyTableListener the itemName parameter is a unique name for an item within the table (as in "Item 1" in the diagramme on page 5). How is this different from the "key" field used in command mode?

Currently we are passing what we thought was the table name into the ExtendedTableInfo as an item in an array of one element (we are specifying the fields in the Update method of an IItemEventListener on the server side within the itemEvent dictionary and are passing what we thought was the table name as the itemName in this method call). This is in command mode using distinct keys in the key field. This seems to work as we thought; we recieve a list of items (single items in quick succession) on snapshot and updates for seperate items as they are updated.

Many thanks.

Having investigated our current code it looks like our table contains a single item. This is replaced each time with any new update. This results in the correct data appearing on the front end, but is obviously suspect (and we will need to reimplement). Does this sound like what could be happening?

1. Does MetadaAdapter have to know the list of items for the table and send them to the LS kernel when a client is subscribing using SimpleTableInfo?

2.When a new item is created should the app server notify both DataAdapter (to actually send data with the add command) and MetadataAdapter (to relate it to the relevant groups when another subscription request is received)? When the DataAtapter is sending data and there are no subscriptions the warning message is being written to the log file.

3. Are snapshots requested for one item or for the whole group?

4. How do we notify the client of new items that need to be subscribed to i.e. expand the set contained within a group so that the client can issue a subscription request for those items?

If you use COMMAND mode, then your approach is now clear.
We just need to agree on the names of the various concepts.

We use the concepts of Group and Item list to define static tables with a fixed number of lines, each of which corresponds to an Item that is usually managed in MERGE mode.

On the other hand, if you subscribe to an item in COMMAND mode, then the item values carry commands that say: "ADD, UPDATE or REMOVE a line based on a specified key".
Hence, by subscribing to a single Item, the client can maintain a whole data table based on the updates received for that single item.
So, if you use items in COMMAND mode, you will usually subscribe to a table that, from Lightstreamer point of view, only contains one Item (i.e. the Group associated to the table is made of only one item).
When only one item is involved, it is not important whether you use a SimpleTableInfo or an ExtendedTableInfo; your Metadata Adapter will receive the item name and shoud pass it through to the kernel (note that the ExtendedTableInfo is to be preferred because it still simplifies the management of the fields).
On the client listener, all updates are referred to the unique item involved, but, for each update, you can extract the value of the "key" field involved. Using a HandyTableListener is recommended.

Please check whether your questions about groups are still needed in this scenario.

1. If we have a dynamic table we should subscribe as described in the initial question?

2. If so it is not clear how the snapshot is working; will lightstreamer cache updated items and be able to send initial data to the client without calling a DataProvider? How will authorization work in this scenario?

3. Having checked our current implementation in the debugger, our IUpdateInfo's GetOldValue() method gets the previous item's value, not the old value for the current item. Is this to be expected in command mode, or should we be receiving the old value for the current item?

about 1) If you use an item in COMMAND mode (i.e. a dynamic table), then it is correct that you use an ExtendedTableInfo and supply a list made of a single name,
which is the name of the item in COMMAND mode in Lightstreamer terms
and the name of the table in you view.
The picture in General Concepts.pdf only refers to the basic case of fixed tables and does not apply to this case. You should not refer to it; we will consider clarifying its context.

about 2) Yes; if a client requests an item in COMMAND mode and other clients are already using it, then Lightstreamer does not ask for it again to the Data Adapter.
It can provide a snapshot to the new client based on its own caching of the updates.
The authorization is still performed at item level: if the new client is allowed by the Metadata Adapter to use the item, it will receive all its data.
If this is not your case and different users should only see subsets of the whole dynamic table, this complicates matters.

about 3) For an item in COMMAND mode, in Lightstreamer terms, all updates pertain to that same item, but each update is implicitly referred to a key value (which is the value of the mandatory "key" field) which identifies the row within the dynamic table.
That said, it is not clear to me what you mean by "item" in your question.
Note that, for an item in COMMAND mode, IUpdateInfo.GetOldValue yields the value on the previous update referred to the same key as the current update.
In other words, it yields the previous value for the row of the dynamic table to which the current update refers.

Thank you, Dario.

What would you recommend doing when subscribing in MERGE mode if we would like to infrequently add or remove items from the table?

We have a situation where many clients will want overlapping, but not the same data from a set. As such we want to avoid COMMAND mode for this case as it would lead to a large number of disparate tables that contain data that could be (and would be in MERGE mode) shared. This set of data will occasionally have items added or removed, but this will be very infrequent when compared with the frequency of data updates.

Would you advise unsubscribing from and resubscribing to the group when rows are added or removed?

Lists of items with many value updates and rare changes of the list contents are suitable for what we call two-level push.

Unfortunately, the .NET client library offers no built-in support for two-level push, unlike other libraries. See the MultiDynaMetapush table in the web client library for instance. Would something similar fit into your case?
You could implement the same logic in your client. In this way, you could provide multiple items in COMMAND mode for different list compositions without redundancies: data for each single line would by provided by a common, dedicated item in MERGE mode.

On the other hand, unsubscribing and resubscribing to the whole group has some disadvantages.
It would be inefficient, because each row would be restarted with a new snapshot (and your table should manage to mask the discontinuity).
Moreover, you would still need asynchronous notifications that the group contents have changed, leading to something similar to the above mentioned "MultiMetapush" technique.

When subscribing with a SimpleTableInfo in MERGE mode, is there a way on the client to get the number of items, or at least get the end of snapshot event for the whole table?

About the snapshots, they come for the various items in the table independently of one another, just like the real-time updates
and there is no notification that all of them have been received.

You could determine that by knowing how many items are in the table,
but, unfortunately, the information on the number of items is indeed lacking for the SimpleTableInfo case.
Do you confirm that in your case the client, at the time of subscription, doesn't know how many items are involved?

To workaround the limitation, your Metadata Adapter, when resolving the group ID in getItems, could add a "sentinel" item as the last element of the returned array.
The sentinel item would just associate a recognizable value to a specific field, so that the client, upon reception of the snapshots, could recognize that value and take the index of the related item as the last one (still, it would be possible that the shapshot for some of the previous items would be yet to come).

Will LS send snapshot events without any updates in this case? Or is it possible that some update events for the items the snapshot was already sent might be slotted into the sequence?

All events pertaining to one item are independent with respect to events pertaining to other items, even if they are subscribed within the same table.

So, it is possible that your client receives
the snapshot for item ItemA
followed by a real-time update for item ItemA
followed by the snapshot for item itemB.

Obviously, this happens in short time, as the Server always sends the snapshots as soon as possible.

Thank you for the clarification.