...
Each time a client subscription filter applies to a cmhandle the filterUsage count is incremented. A filter that could already have been applied to a cmhandle would get its filterUsageCount incremented if a new subscription applies to a cmhandle that already has the filter applied to it. This helps when removing subscriptions... the filterUsageCount will be decremented each time a filter is removed. When filterUsageCount goes to zero the associated cmhandles can be easily identified for update to remove that filter. Simple DB design to identify affected cmhandles - can also use foreign keys to do similar.
CmHandle related tables in the DB will be updated to store the subscription state for the appropriate cmhandle datastores
Data similar to the below needs to be reflected in the related cmhandle data model
{ "subscriptions" : { "running" : { # 'local' ncmp subscription is required with the cmhandle - store subId separately? "passthrough-operational" : { "passthrough-running" : { } |
|---|
The subscriptionId in the passthrough-* datastore subscription information represents the subscription created on the remote device.
DMI plugin sends this subscriptionId of the device to NCMP in the subscription response event after successful subscription on the device.
The subscription may be different on the device if setting up a subscription toward different datastores. If the device only supports running datastore (non-NMDA) then all subscriptions are directed toward the running datastore regardless of whether passthrough-running or passthrough-operational is specified in the subscription. It would mean that the same notification would be sent twice but the eventSource would differ (passthrough-operational and passthrough-running). However, this is a concern for the dmi plugin only - not for NCMP.