entity and link removal and recreation

[gotjoshua]

I have 2 questions, which i think are bugs:

1. I have a link from IDentry - > PassDetailEntry, and I delete the PassDetailEntry, why doesn't the link get automatically removed (as it is pointing to a non-existing entry)?

2. Even if I manually delete the link before deleting the entry, why can't i recreate the PassDetail Entry with the same properties?
   I get this:
   {"Err":{"Internal":"{\"kind\":{\"ErrorGeneric\":\"Target for link not found\"},\"file\":\"crates/core/src/nucleus/ribosome/runtime.rs\",\"line\":\"220\"}"}}

The issue i'm working on is here:
tatssato/holomasterpass#6

The code is here:
zomes/passwords/code/src/lib.rs#L167

The app is usually running here (but no promises for uptime):
http://holoapp.onezoom.in/

[pdaoust]

@gotjoshua

1. deleting links when the target is deleted

I agree that that would be the logical action -- delete the target, and the link gets deleted too. This is how SQL databases work after all. However, on Holochain you're often responsible for your own referential integrity; that is, you often have to clean up some things like links or targets yourself. That's because, in a hash-based database that's distributed across the planet, nobody has a good way of knowing who should be notified when something gets deleted. For example, the nodes holding the target don't have any way of knowing what other entries are linking to that target.

I suppose that we could introduce logic to have the nodes holding the link inform the nodes holding the target of the existence of the link, then the holders of the target could call those nodes back when the target gets deleted, but that introduces eventual consistency problems -- the nodes holding the target would never have a guarantee that they have the full list of links pointing to the target. Whereas if the agent deleting the target is also responsible for finding all the links that point to it and deleting them as well, you still don't have any guarantee that all the links will be deleted, but at least there's not an implied expectation that it'll do things cleanly; all you're doing is deleting the links you know about.

The same is not true of the base entry; if you delete the base entry, the links disappear along with it. One of the quirks of working with the DHT.

It does make me wonder if there are good patterns, that we haven't discovered, that lead to something closer to what devs would expect from a database system. Worth chewing on, hmm... thanks for the challenge 👍

2. Trying to recreate a deleted entry

Deletion events in Holochain are always-and-forever. That's because it's implemented with a CRDT called a tombstone set -- this is an algorithm that collects creation and deletion and events and defines a conflict resolution rule that says "delete always wins, no matter how many times the data has been recreated".

What you could do is add some sort of 'nonce' to the PassDetail record -- perhaps that's a tuple of (agent ID, time added), or maybe you simply enforce that the counter field always has to increment by one for a given name field -- it's cheap to throw away old passwords and derive new ones, after all. This nonce value would cause otherwise identical PassDetail entries to have different hashes so you could keep deleting and re-adding without clashes.

Anyhow, we could talk more about this on the forum if you like -- I'd be happy to dig into the design with you!

[gotjoshua]

OK, so actually the link is deleted, but that error comes when trying to recreate the link to an already deleted entity!!!
Kapish.

I started a thread on the forum to continue...