Modifying graph during query traversal?


#1

I’m interested in the feasibility of modifying a graph during a query traversal. It looks like this is possible in TinkerPop3 but I’m basing that off this as I’ve never used it. Given that, looks like it’s something in the realm of possibility.

I know the ability to update entities without first deleting them is something on Grakn’s radar but is something like modifying the graph during a query traversal on the radar? I ask because I’m facing a concurrency issue where updating the graph during the initial query would fix quite nicely.


#2

Follow up question: Are you able to query Grakn and have it output a traversal path that can be walked like the example code in the link I provided? If it’s in the documentation and I missed it, sorry.


#3

hi @BFergerson,
If I understand your question correctly, the closest we get to this is to do:

  1. match-insert and match-delete, or
  2. .stream() the answers from one query, perform the modifications and output the result into another stream, and use that stream as input to more Graql queries (be cautious of the computation expense of this).

Does that help your case?


#4

@haikal, I was able to code around the concurrency issue I was facing outside of Grakn. I think it might still be a useful feature but no rush on my part.

As for the second question, I’m asking if Grakn can expose the traversal it takes with the query. You’re saying that I should run a query, get an answer, run another query, get the final answer. I’m asking if I make a query which starts from nothing and gets me the final answer; Can I instead of getting the final answer get the traversal path which is performed by Grakn which leads to that final answer? This is different than running queries and getting answers which you then use to fuel further queries.

I think this would help with debugging and just my general understanding of what Grakn is actually doing under the cover. I know I can turn logging on but I’m struggling to understand how to follow them. If instead I could get the traversal path that Grakn performs and iterate it I could see it’s doing 50,000 loops in some section of the graph that it should have never got to (or some other crazy but realistic traversal path).