getPropertyKeys throws ELEMENT_ALREADY_DELETED

[Giuseppe Santoro]

If you delete an element and then, before commit, you call the method getPropertyKeys will throw an ELEMENT_ALREADY_DELETED.

In my use case I'm implementing a delete with cascade of some vertex/relationship, when I want to print the properties of a "just" deleted node or relationship (this can happens because I'm traversing the graph) I get this error.

I think it should be not thrown, what do you think about it?

[Sridhar Ramachandran]

Bitsy only supports getId() deleted nodes/edges, and on vertices/edges outside the transactional scope. I kept it strict to catch bugs in the calling application.

I had several cases in my app where I was making modifications to deleted nodes, or nodes from a different transaction. This was causing unpredictable behavior in the previous database I was using (prior to developing Bitsy). This is the reason for the strict checks.

I have a cascading-delete use-case in my app, where I do something like this:

void removeSomeVertex(Vertex v) {
   for (... loop over outgoing edges...) {
      ... delete edge
      ... recursive call to removeSomeVertex on the in vertex
   }
   ... add debug message on removing the vertex
  v.remove();
}

This ensures that you are not accessing deleted edges or vertices, and won't get stuck in infinite loops.

You can also implement the same thing with a Stack to avoid StackOverflow in deep graphs. I think the depthFirst method in this post shows such an implementation. You won't need this unless you have a very deep cascading delete.

Let me know if this works. My preference is to keep the database behavior strict.

[Giuseppe Santoro]

Thank you for your response, I understand your point of view, that is absolutely correct.

In this moment, my traversal code is written through a gremlin pipeline so I can not assert the navigation behavior, at least I think.

However we can consider the proposal closed. Thank you again.