Entity expiration if it doesn't receive an update in a given time

[fgalan]

We have transient entities functionality since Orion 1.15.0.

However, in addition of using a fixed date it will be great to add the capability of expire (and delete) the entity if no update on it has been received within a given ~date~ time (real updated? or any update, i.e. even the ones don't actually change any attribute value?).

It is a matter of dynamically chaning the extDate field in the DB document associated to the entity each time the entity is updated. It seems feasible.

[Anjali-NEC]

Hi @fgalan Sir,

I would like to work on this issue, Please let me know this issue is still need to fix or not

[fgalan]

This issue is valid and it would a very useful feature. Please go ahead. Thanks for your willingness to work on it!

[Anjali-NEC]

We have transient entities functionality since Orion 1.15.0.

However, in addition of using a fixed date it will be great to add the capability of expire (and delete) the entity if no update on it has been received within a given date (real updated? or any update, i.e. even the ones don't actually change any attribute value?).

It is a matter of dynamically chaning the extDate field in the DB document associated to the entity each time the entity is updated. It seems feasible.

As per my understanding currently the expDate field have a fixed date of expire (and delete) the entity if no update on it has been received within a given date. We need to make expDate field dynamically changing in the DB document each time the entity is updated. Please confirm my understanding.

[fgalan]

First of all, I'd recommend to have a look to the documentation at https://fiware-orion.readthedocs.io/en/master/user/transient_entities.html on how the feature of transient entities currently works.

I see two alternatives, from a functional point of view (i.e. implementation apart)

Alternative 1:

Add a new special field (let's name it maxAge by the moment) keeping the logic and behaviour of dateExpired as it is. The value of maxAge would be a number in minutes (*) so if the time of the last update on the entity is older than that time then the entity is automatically deleted. Both dateExpired and maxAge features would operate at the same time.

For instance in a given moment an entity has:

{
  "id": "t1",
  "type": "Ticket",
  ...
  "dateExpires": {
    "value": "2028-07-07T21:35:00Z",
    "type": "DateTime"
  },
  "maxAge": {
    "value": 60,
    "type": "Number"
  }
}

The entity will be automatically deleted when the first of these conditions happens:

• Time overpasses 2028-07-07T21:35:00Z
• The entity is not updated in the last 60 minutes, no matter which time is

(*) It doesn't make sense to use seconds as unit, as the MongoDB thread in charge of deleting expired documents wakes up every 60 seconds.

Alternative 2

Overload the dateExpired attribute, so:

• If attribute type is DateTime it behaves as it is now
• If attribute type is Number it behaves as in the maxAge case described for alternative 1

This alternative has the advantage that no extra attribute needs to be defined (so avoiding collision of existing usage of maxAge) at a cost of overloading an existing attribute.

[mapedraza]

IMHO Alternative 2 makes more sense since it does not take another attribute name for an special functionality, even if dateExpired is not so aligned with the concept of "time (or seconds) to expire". On the other hand, overloading depending on the attribute type is a really good idea.

[fgalan]

IMHO Alternative 2 makes more sense since it does not take another attribute name for an special functionality, even if dateExpired is not so aligned with the concept of "time (or seconds) to expire". On the other hand, overloading depending on the attribute type is a really good idea.

Let's try alternative 2 :)

@Anjali-NEC please consider alternative 2 and evaluate the complexity of implementing it