This is something we discussed in last Hackathon (along with not keeping track of children in the parent) and I did a prototype at some point for both but I was running into some problems. I don't remember whether they were issues related to deleted flag or about not keeping track of children in the parent. Maybe we should open a bug and try again, at least the deleted flag part?
-Mete On 1/10/13 11:07 AM, "Marcel Reutegger" <[email protected]> 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
