Streaming: DELETE and/or TOMBSTONE

[roshan-joyce-fujitsu]

Raising a confusion after reading through TR548 v2.0 and the yang in 2.4.1.
Please see if we need to add further clarifications in TR548.

1. When an entity is deleted in the controller, should the TAPI Streaming Provider supply 2 log-records to the client? One with record-type==RECORD_TYPE_DELETE and another with record-type==RECORD_TYPE_TOMBSTONE?
2. If yes, what would be the reason/benefit?
3. If yes, should there be an order for the 2 log-records? DELETE first and then TOMBSTONE? Or the other way?
4. Is there an expectation that a log-record of type TOMBSTONE, the field log-record-body/record-content is mandatory. The reason for this question is the phrasing in page-36 where it says record-content: Note that for a DELETE, there is no need for content and hence this field may be omitted. I hope it can be same in TOMBSTONE log-record also.
   Actually, record-content is just an identity string identifying the object-class. And there is a class-specific augment that inserts a container to represent the actual content. So, perhaps we can include record-content in both DELETE and TOMBSTONE to indicate the object-class and avoid the augment with the actual contents of the deleted object.

Related sections in TR548 v2.0:

• Page 36, 60, 78, 79, 81, 83
  In these pages, for some statements DELETE and TOMBSTONE are treated the same way but in some other statements they are not.

[nigel-r-davis]

Thanks for the comment.

1. When an entity is deleted in the controller, should the TAPI Streaming Provider supply 2 log-records to the client? One with record-type==RECORD_TYPE_DELETE and another with record-type==RECORD_TYPE_TOMBSTONE?

   • Response: Yes.

2. If yes, what would be the reason/benefit?

   • Response: The delete is used when there has been no compaction. The delete can carry additional information about the reason etc. and provides the parent address etc. The tombstone is a very small structure with just the uuid of the entity that has been deleted. It carries no further details. The small structure allows for a longer retention of information of the deletion and hence allows a client to not need to fully realign even after a long comms failure.

3. If yes, should there be an order for the 2 log-records? DELETE first and then TOMBSTONE? Or the other way?

   • Response: The records should be logged delete followed by tombstone such that on compaction it is the tombstone that is left.

4. Is there an expectation that a log-record of type TOMBSTONE, the field log-record-body/record-content is mandatory. The reason for this question is the phrasing in page-36 where it says record-content: Note that for a DELETE, there is no need for content and hence this field may be omitted. I hope it can be same in TOMBSTONE log-record also.
   Actually, record-content is just an identity string identifying the object-class. And there is a class-specific augment that inserts a container to represent the actual content. So, perhaps we can include record-content in both DELETE and TOMBSTONE to indicate the object-class and avoid the augment with the actual contents of the deleted object.

   • Response: As noted above, the tombstone always has no content other than the id. The delete can carry more content.

[nigel-r-davis]

Thanks for highlighting the page numbers (in V2.0) I will take a look at this text and will attempt to improve the clarity.