Command Mode Delete Processing Question

wwatts

With our .NET 4.0 thick client (custom .NET adapters/Presto version 4.02) we would like to manage COMMAND mode DELETES in such a way that the
client can inspect the type of delete received and determine from this how to manage its local data cache. However upon inspecting the IUpdateInfo
data received from Lightstreamer, only the event item ID and command (DELETE) are included in the payload. This behavior remains the same
irrespective if the Data Adapter sends the all the item event name / value pair data to Lightstreamer as part of the COMMAND mode DELETE payload.
(Please note that when we sent all the item event's name/value pairs to Lightstreamer, one field (delete transaction type) had been updated to
reflect a delete type classification value.)

Is there any way to either:

1. Include another field (name/value pair) in addition to the command and event item ID with a COMMAND mode DELETE transaction that would be received on the .NET client? (This field would represent the type of delete that has occurred.)

2. Or have Lightstreamer send all the event item's name / value pairs as part of the COMMAND mode DELETE transaction payload (IUpdateInfo)

The listing below documents the COMMAND mode ADD, UPDATE and DELETE IUpdateInfo object contents received on the .NET thick client:

[Lightstreamer.DotNet.Client.UpdateInfoImpl] =

ADD

{[ 14013, ADD, EVT, 2, , 0, 0, , , 0, , , , 0320, NSPT, AAAA-A, 2/22/2011 8:00:00 PM, 600, 2/22/2011 8:10:00 PM, , , , 0, BXK, Lightstreamer ADD., , DDD, , , , , 0, , , , , , , , , 14013, 14013, 1, 2/22/2011 8:01:36 PM, , 0, False, 0, 0, , True, , , , , NonSupport, 0, True, False, , , 2/22/2011 8:00:00 PM, False, 29, False, False, , ]}

---
UPDATE (A time value was changed to 8:20 PM)

{[ (14013), UPDATE, (EVT), (2), (), (0), (0), (), (), (0), (), (), (), (0320), (NSPT), (AAAA-A), (2/22/2011 8:00:00 PM), 1200, 2/22/2011 8:20:00 PM, (), ( ), (), (0), (BXK), Lightstreamer UPDATE., (), (DDD), (), (), (), (), 1, (), (), (), (), (), (), (), (), (14013), (14013), 2, 2/22/2011 8:06:46 PM, (), (0), (False), (0), (0), (), (True), (), (), (), (), (NonSupport), (0), (True), (False), (), (), (2/22/2011 8:00:00 PM), (False), 31, (False), (False), (), () ]}

---
DELETE

{[ (14013), DELETE, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null,
null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null,
null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null,
null, null, null, null, null, null, null, null, null, null, null, null, null ]}

Giuseppe Corti

I confirm you that the COMMAND mode DELETE ignores all other fields except item ID and command.
So the behavior of what your thick client receives is consistent with Lightstreamer specifics.

Mode COMMAND action DELETE can be associated as a physically delete while your scenario is more like logical delete.
(You do not want the whole item disappears from client, at least not right away, I'm correct?).

A workaround I can suggest you is to split your current delete action in two events:
- An UPDATE with the new value for the delete transaction type field and any other appropriate fields;
- A DELETE.
Please note that in this case in your subscriptions you should set the "unfiltered" flag in order to avoid that the server merges the two events.
I think that in such a way your client can inspect the local data cache after UPDATE event received and determine from this how to manage the subsequent DELETE.

Hope this Help.

Giuseppe