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
Using aggregates fits perfectly for having unique key/value sets of entities. We can create and update them, but without supporting deletions the only option that a user has is to set values to null or some arbitrary value that identifies this "deleted" status.
Doing this logical deletion brings to problems:
The user need to parse the aggregation and filter this values on client side each time the it is fetched from the API
The orphans keys consume unnecessary resources on the CCN
Opinion:
Would be nice to have a way to delete this keys instead marking them as null. But legacy behavior is to keep all keys even if the value is null, and in some cases a use could want to have a null value associated to a key without loosing that key
Proposal:
Either:
Implement an improvement on aggregate logic to define an arbitrary value FORGET for example, to delete keys by merging a new message:
{foo: 1,bar: 2}+{foo: 'FORGET'}={bar: 2}
Create an additional endpoint for squashing null values on demand from an aggregation without interfering on the current behavior
The text was updated successfully, but these errors were encountered:
Problem:
Using aggregates fits perfectly for having unique key/value sets of entities. We can create and update them, but without supporting deletions the only option that a user has is to set values to
null
or some arbitrary value that identifies this "deleted" status.Doing this logical deletion brings to problems:
Opinion:
Would be nice to have a way to delete this keys instead marking them as null. But legacy behavior is to keep all keys even if the value is null, and in some cases a use could want to have a null value associated to a key without loosing that key
Proposal:
Either:
FORGET
for example, to delete keys by merging a new message:The text was updated successfully, but these errors were encountered: