search

derekkraan / delta_crdt_ex

Use DeltaCrdt to build distributed applications in Elixir
MIT License
493 stars 36 forks source link

Using atom as a key possibly fail the VM #35

Closed jung-hunsoo closed 5 years ago

jung-hunsoo commented 5 years ago

I think it's better to add an issue here than merkle_map or horde, because the merkle_map is another kind of a map and horde leverages this library.

It looks the DeltaCrdt uses atom-type keys to propagates data, like %{"CRDT" => "is magic!"}. src

That means whenever a mutation is occurred, a new atom can be created across the nodes which never garbage collected.

How about broadcasting data across the nodes to their own Agent to avoid bloating atom table?

derekkraan commented 5 years ago

Do you mean if you do something like DeltaCrdt.mutate(crdt, :add, [:atom_key, "value"])? Or something else?

jung-hunsoo commented 5 years ago

Both mutate/4 and mutate_async/3 calls DeltaCrdt.CausalCrdt.handle_operation/2 which access MerkleMap.put(mm, key, value) when adding a data.

derekkraan commented 5 years ago

Yes, but this only applies when using :atom_key or similar, correct?

jung-hunsoo commented 5 years ago

OMG Sorry, I was totally confused. You're correct. It's good enough not to use atom type as a key.

derekkraan commented 5 years ago

:joy: no worries, thanks for reading the source code!

jung-hunsoo commented 5 years ago

Sorry for reopen. Though I don't think an inexperienced developer would use this lib or horde, how about adding a guide not to use atom type as a key? Any atoms either a key or a value will be replicated over the nodes but not eliminated.

derekkraan commented 5 years ago

I would accept a PR adding a warning about this to the docs or the readme, or both.

derekkraan commented 5 years ago

Also note: using an atom in the value will have the same result as using an atom in the key.