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
Hello. I have a specific case where I use following connection topic _/_/things/twin/events?extraFields=features/{{feature:id}},thingId&filter=like(resource:path,'/features/SoftwareUpdate*') to consume change notifications by stateless service, which are enriched for other contextual data from the same feature even in case of partial feature modification. Currently it happens in case of concurrent modify commands, that extra field contains different values than actual changes in value field (see screenshot).
Since ditto supports retrieving historical revisions, the proposal is to provide deterministic and strong consistency by not looking up the current state, but the state at the revision number of the processed event. However, in some other use cases it may be more efficient to keep the caching implementation.
Thank you.
The text was updated successfully, but these errors were encountered:
Hello. I have a specific case where I use following connection
topic _/_/things/twin/events?extraFields=features/{{feature:id}},thingId&filter=like(resource:path,'/features/SoftwareUpdate*')
to consume change notifications by stateless service, which are enriched for other contextual data from the same feature even in case of partial feature modification. Currently it happens in case of concurrent modify commands, thatextra
field contains different values than actual changes invalue
field (see screenshot).Since ditto supports retrieving historical revisions, the proposal is to provide deterministic and strong consistency by not looking up the current state, but the state at the revision number of the processed event. However, in some other use cases it may be more efficient to keep the caching implementation.
Thank you.
The text was updated successfully, but these errors were encountered: