Reg PRUNE using variable

[Harikrishnan Gnanamoorthy]

Hello ArangoDB Users,

I am new to ArangoDB and we are exploring Graph traversal capabilities for our use case.

I was trying to use PRUNE operator to stop the traversal of Graph. PRUNE operator tries to use the condition using custom variable defined in the AQL;

When I run the AQL, I got the error "AQL: Syntax error, unexpected identifier near PRUNE (!IS_NULL(edge)....'

My intention is to stop the traversal if the condition is met. Please let me know if this is possible to achieve in ArangoDB AQL. Kindly suggest me if there are alternatives to achieve the similar functionality. Thank you

AQL Query is as below:

FOR i IN vertex
    FILTER i._id == "some input"
    FOR vertex,edge, path IN 1..2 OUTBOUND i graph_collection
        LET c = (
                    SORT vertex.OPTION[*].CREATE_DATE DESC
                    RETURN {
                        relDate: (CHAR_LENGTH(vertex.OPTION[*].CREATE_DATE) == 0 ? '1900-01-01 00:00:00' : vertex.OPTION[*].CREATE_DATE)

                  }
                )
        LET rel=DATE_FORMAT(c[0].relDate,'%yyyy-%mm-%dd %hh:%ii:%ss')
        LET cin = DATE_FORMAT(edge.INPUT_DATE,'%yyyy-%mm-%dd %hh:%ii:%ss')
        LET cout = DATE_FORMAT(edge.OUTPUT_DATE,'%yyyy-%mm-%dd %hh:%ii:%ss')
        PRUNE (!IS_NULL(edge) AND cin > rel AND cout <= rel)
        RETURN {
                key:vertex.OBJ_NUMBER,
                dt: rel

            }

[Simran Spiller]

PRUNE isn't a stand-alone operation; it belongs to the FOR ... IN loop. You can't place things like LET in between (and also not have subqueries in the PRUNE expression).

FOR vertex,edge, path IN 1..2 OUTBOUND i graph_collection

PRUNE ...
LET ...

Moreover, the LET c = ( ... ) subquery doesn't do anything meaningful like this. The subquery doesn't iterate over anything, therefore there isn't anything to SORT. What you potentially want is:

FOR create_date IN vertex.OPTION[*].CREATE_DATE
SORT create_date DESC

CHAR_LENGTH(vertex.OPTION[*].CREATE_DATE) == 0 will never be true, because the inner expression evaluates to an array and CHAR_LENGTH() will cast that to a string, with the shortest one being "[]", so 2 characters.

You should consider changing your data model so that you don't need all the date-related transformations at query time.