New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

More granular subscriptions modes (create only, update only, delete only and combinations) #1494

Open
fgalan opened this Issue Nov 11, 2015 · 8 comments

Comments

Projects
None yet
3 participants
@fgalan
Copy link
Member

fgalan commented Nov 11, 2015

NGSIv1 uses ONCHANGE notifications, which triggers each time a new context element (entrity + attribute) is created and/or updated. Thus, it is not granular enough to difference between create and update and it is not able to trigger notifications upon context element deletion.

NGISIv2 should improve this and include the following modes:

  • Notify when the context element is created (only)
  • Notify when the context element is updated (only)
  • Notify when the context element is deleted (only)
  • Any combination of them (e.g. created+updated, created+deleted, created+updated+deleted, etc.)

In addition, notifications should include some way of specifying if the context element was created, updated or deleted.

The condition field in NGSIv2 subscriptions should be reviewed in order to see how it can be adapted to these behaviours.

(Mabye there are duplicate issues about ONCREATE or ONDELETION semantics...)

@tobiasjacobs

This comment has been minimized.

Copy link
Contributor

tobiasjacobs commented Nov 18, 2015

Not sure if we talk about the same thing, but

  • In my understanding a context element contains an entity id (+type) and several attributes with values.
  • Context Elements are also not really created/updated/deleted in NGSI, but they are data containers to transmit one or more attribute values of a context entity.

Anyway, I think what you propose is to define different subscription modes in order to

  • get a notification whenever an attribute value becomes known
  • get a notification whenever the value of an attribute becomes known to have changed
  • get a notification whenever an attribute value becomes unknown

@fgalan fgalan added this to the NGSIv2SpecPending milestone Jun 22, 2016

@fgalan fgalan added the P5 label Aug 3, 2016

@fgalan

This comment has been minimized.

Copy link
Member Author

fgalan commented Sep 22, 2016

A way of specifying to which case (update, create, delete) a given attribute in the notification corresponds (see actionType metadata introduced in #2518). However, the way of setting to which evetns the subscription has to react has to be defined.

It is a just a matter on how to "code" that configuration in the subscripton payload.

@jmcanterafonseca

This comment has been minimized.

Copy link
Collaborator

jmcanterafonseca commented Sep 22, 2016

We need to distinguish between actions referring to entities and actions referring to attributes.

I guess that if attrs is not defined or empty we will be referring to the whole entity and if not we will be referring to a particular attribute or attributes.

{
  "subject": {
    "actionType": "update"  /* ("delete", "append", "create", "change") */
  }
}

The difference between update and change would be that change will imply a change in the attribute value whereas update will imply an update of the element which could result in a attribute value change or not.

For backwards compatibility, no actionType will mean "change".

What do you think?

@fgalan

This comment has been minimized.

Copy link
Member Author

fgalan commented Sep 22, 2016

Note from #2518 (comment), to take into account in the context of this issue:

what should happen if the attribute was not formerly defined. I think in that case this metadata should not appear. But we need to specify it.

@fgalan

This comment has been minimized.

Copy link
Member Author

fgalan commented Oct 10, 2016

Functional specification

Based on the @jmcanterafonseca idea, but with some changes:

  • The actionType would be part of subject.condition (instead of root subject) given it is actually defining an aspect of the condition.
  • actionType would be a list, specifying which events trigger the notification. The different elements in the list are interpretead in OR way.
    • update: notification is triggered whenever a triggering attribute is updated (no matter if the attribute is actually changed or not)
    • change: notification is triggered whenever a triggering attribute is updated and it actually changes
    • append: notification is triggered whenever a triggering attribute is created
    • delete: notification is triggered whenever a triggering attribute is deleted
  • Default value for actionType (i.e., what to use if actionType is not specified at creation/modification time) is the following, which ensures backward compatibility:
[ "change", "append" ]

(triggering attributes = the ones in conditions.attrs)

The .apib file needs to be modified accordingly to describe the new fields.

@fgalan

This comment has been minimized.

Copy link
Member Author

fgalan commented Oct 10, 2016

Implementation notes:

Have a loook to the skip field in ContextAttribute class and how it is used to mark an attribute as deleted in the entity memory image that is keep during the update process. It may be useful to detect which attributes were deleted so a notification has to be triggered in that case of actionType includes delete.

static void deleteAttrInNotifyCer
(
  ContextElementResponse* notifyCerP,
  ContextAttribute*       targetAttr
)
{  
  for (unsigned int ix = 0; ix < notifyCerP->contextElement.contextAttributeVector.size(); ix++)
  {
    ContextAttribute* caP = notifyCerP->contextElement.contextAttributeVector[ix];
    if (caP->name == targetAttr->name)
    {
      caP->skip = true;
    }
  }
}

@fgalan fgalan added APIv2.1 and removed APIv2 P5 labels Jul 12, 2018

@fgalan

This comment has been minimized.

Copy link
Member Author

fgalan commented Jul 12, 2018

Out of the scope of NGSIv2, althouth it is a good idea that could (potentially) be included in a later version of the API (v2.1) in a backward compatible way.

CC: @jmcanterafonseca

@fgalan fgalan removed this from the NGSIv2SpecPending milestone Jul 12, 2018

@fgalan

This comment has been minimized.

Copy link
Member Author

fgalan commented Jan 18, 2019

The following post in SOF should be edited upon issue completion: https://stackoverflow.com/questions/54220061/orion-subscriptions-do-not-detect-the-removal-of-entities

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment