Hi,
This is only loosely related but, checking for nodes which don't exist is expensive across the stack. It currently always results in a full round trip. I think we should at some point come up with some kind of negative cache. Using a bloom filter for this would only add very little memory overhead but might save us quite some round trips.
Michael On 10.1.13 10:07, Marcel Reutegger wrote:
Hi, I was just thinking the way how MongoMK handles deleted nodes and I'm wondering if we should change it to make reading nodes less expensive. I understand reading a node requires checking all ancestors of that node to find out if it really exists. This is already done that way in NodeExistsCommand but it looks like it's missing in FetchNodesActionNew. To me it looks like we will have to change FetchNodesActionNew accordingly. But that means reading will become quite expensive. Would it be better to mark a node as deleted in the revision it was deleted? Reading a node in a given revision would return the node and we'd have to add logic to check the new flag. But we'd then immediately know whether the node exists in that revision without consulting ancestor nodes. regards marcel
