0
votes

I am trying to figure out how to update edge documents using a graph traversal query in arangodb. I am able to do this using the standard FOR e IN collectionName UPDATE e with {newProps} IN collectionName. However I cannot figure out what is wrong with my attempt to accomplish the same thing using the FOR v, e, p IN 1..5 OUTBOUND @startId GRAPH @graphName syntax.

I am using the arangodb:latest docker image on macOS Mojave 10.14.3, and I am using arango's go library (github.com/arangodb/go-driver) to query by building a query string and sending it using the Database.Query() function. I have tried just returning the key for the edge I'm trying to update (i.e. just returning e._key instead of attempting to update in the query below), and have verified using arangosh that that is indeed the correct key of the edge I'm trying to update. Additionally as stated above, I have been able to update an edge using the relational AQL syntax.

Here is my query:

FOR v, e, p IN 1..5 OUTBOUND @startId GRAPH @graphName
    FILTER e.@key0 == @val0
    UPDATE e._key WITH {@propName0: @propValue0} IN has_skill
    RETURN {new: NEW, old: OLD}

and here are my bind variables:

[graphName:Matthew_Loughney, key0:_from, propName0:testProp, propValue0:testVal, startId:applicant/232, val0:applicant/232]

I would expect that when I view the has_skill collection using arangosh, I would see that my edge now has a property testProp with value testVal; however, I instead just get the error AQL: document not found (while executing) and my edge remains unchanged.

1
So if you remove the update (last two rows of your AQL) and just return e._key, does that return only your record? Also since e.@key0 is actually the _from field of the edge, this means it will try to update any type of edge that starts at @val0. Are all the edges in the traversal of type 'has_skill' (you are traversing 5 steps in your query). If any of the edges start at node @val0 and are not of type has_skill, you would get the error above when the system tries to do the updatecamba1
Yep, that was the issue, thanks.Matthew Loughney

1 Answers

0
votes

It turned out that my filter was returning some edges not in the has_skill collection (4 total to be exact), so when it tried to update in has_skill, it succeeded for the one I wanted but failed for the other 3, and since the UPDATE operation is atomic that made it fail for all of them. I did not notice this because I was only looking at the first edge returned when looking at the keys, and this wasn't an issue in my FOR e IN collectionName query because obviously those are all in the correct collection, so that only returned the 1 edge I was looking for.