You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In some scenarios one may record some kind of limited history in a twin like e.g. productivity of the last 12 hours.
This can be modelled today with arrays or a special struct architecture but not very elegant (with simple updates of one value).
This could be overcome if each property could have an optional TTL and Ditto takes care of automatically removing the property when the TTL is expired.
Then one could simply push values (as in the example above) as properties "timestamp" -> value and set the TTL accordingly to 12h.
One idea could be to implement this with regards to the extended metadata model in #680.
The text was updated successfully, but these errors were encountered:
I would try to start with the implementation of this after #680 / #745 is finished. My first approach would be to store a special metadata about the TTL in the metadata of the thing and check in the AbstractThingEventStrategy if a property needs to be removed.
Does that make sense or do you suggest another approach @thjaeckle ?
That sounds reasonable.
What we would need then is a class/enum/whatever where the Ditto "known metadata" fields are defined.
"Knowing" meaning that Ditto has to apply semantic meaning to that metadata and does something automagically.
In some scenarios one may record some kind of limited history in a twin like e.g. productivity of the last 12 hours.
This can be modelled today with arrays or a special struct architecture but not very elegant (with simple updates of one value).
This could be overcome if each property could have an optional TTL and Ditto takes care of automatically removing the property when the TTL is expired.
Then one could simply push values (as in the example above) as properties "timestamp" -> value and set the TTL accordingly to 12h.
One idea could be to implement this with regards to the extended metadata model in #680.
The text was updated successfully, but these errors were encountered: