[Feature] Deleting top-level keys

[joaomlneto]

Hi!
Is it possible to delete top-level keys (i.e. from a bucket)?
If so, this doesn't seem to be exported through any of the APIs (Java/TypeScript).

[marc-shapiro]

My understanding is that a key is neither created nor deleted. Initially it has the “bottom “ value for its data type. Resetting it to “bottom “ is the closest you get to “delete “. This is by design :-) Marc

…

Le 28 févr. 2018 à 14:55, João Neto ***@***.***> a écrit : Hi! Is it possible to delete top-level keys (i.e. from a bucket)? If so, this doesn't seem to be exported through any of the APIs (Java/TypeScript). — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[preguica]

There has been some discussion of whether it would be interesting to support delete or not -- I am in favor of supporting it :-) Could you share with us the use case where it would be interesting to have delete. Thanks, Nuno

…

On Wed, Feb 28, 2018 at 7:58 PM, Marc Shapiro ***@***.***> wrote: My understanding is that a key is neither created nor deleted. Initially it has the “bottom “ value for its data type. Resetting it to “bottom “ is the closest you get to “delete “. This is by design :-) Marc > Le 28 févr. 2018 à 14:55, João Neto ***@***.***> a écrit : > > Hi! > Is it possible to delete top-level keys (i.e. from a bucket)? > If so, this doesn't seem to be exported through any of the APIs (Java/TypeScript). > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub, or mute the thread. > — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#325 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJZR8vywTVD4AjCM4F4FMp430ZRLgfXGks5tZaG4gaJpZM4SWsIn> .

[joaomlneto]

Hi Marc & Nuno! Thanks! :)

I guess Roger asked about the possibility (LightKone/antidote-rest-server#11); probably without any specific use-case in mind (more in terms of testing).

My understanding is that the reset operation will only revert the value of the object back to its zero-value, but won't change the type of the object (i.e. the beatles key which represents the set of members of the band cannot be changed later into representing a counter of how many beatles we find in our music store).

A few questions:

• Why are the semantics for keys in a bucket different from keys in a map?
• What are the limitations in providing a setKeyType(CRDT_TYPE) sort of operation? Probably due to nasty effects when having concurrent operations (e.g. counter.increment() || set.add("ringo")?
  • What if instead of mapping (key)-->(object) we map (key, crdtType)-->(object)?
    • This allows multiple CRDT object types per key
    • Operations on different CRDTs won't conflict (as they are applied to different objects)

I mean, it's just a suggestion. One that probably makes Antidote more complex without any real use-case backing it.
Was just wondering if my thinking was OK, or there's something I'm not considering.

[bieniusa]

Hey,

the semantics of keys in buckets and maps are mainly different because the map has been designed much later and with more insight. I agree that we should try to align the semantics of both 👍

Personally, I am not in favour of offering a "delete" operation where the semantics differ from a reset. I think it would mess up the semantics of concurrent modification and deletion.
We should discuss whether a key is always mapped to a specific type (in which case your setKeyType(...) operation would be very useful), or if we can have the same key with different type (which has the better concurrency semantics, but might be confusing for the programmer?).

We have discussed both in the past, but didn't come to a conclusion.