Github user dkuppitz commented on a diff in the pull request:

    https://github.com/apache/tinkerpop/pull/882#discussion_r207377923
  
    --- Diff: docs/src/recipes/shortest-path.asciidoc ---
    @@ -136,3 +158,44 @@ g.withSack(0.0).V().as("from").       <1>
     <7> Order the output by the start vertex id and then the end vertex id 
(for better readability).
     <8> Deduplicate vertex pairs (the shortest path from `v[1]` to `v[6]` is 
the same as the path from `v[6]` to `v[1]`).
     
    +Again, this can be translated into an OLAP query using the 
`shortestPath()` step.
    +
    +[gremlin-groovy,existing]
    +----
    +result = g.withComputer().V().
    +  shortestPath().
    +    with(ShortestPath.distance, 'weight').
    +    with(ShortestPath.includeEdges, true).
    +  filter(count(local).is(gt(1))).
    +  group().
    +    by(project('from','to').
    +         by(limit(local, 1)).
    +         by(tail(local, 1))).
    +  unfold().
    +  order().
    +    by(select(keys).select('from').id()).
    +    by(select(keys).select('to').id()).toList()
    +----
    +
    +The obvious difference in the result is the absence of property values in 
the OLAP result. Since OLAP traversers are not
    +allowed to leave the local star graph, it's not possible to have the exact 
same result in an OLAP query. However, the determined
    +shortest paths can be passed back into the OLTP `GraphTraversalSource`, 
which can then be used to query the values.
    +
    +[gremlin-groovy,existing]
    +----
    +g.withSideEffect('v', []).                            <1>
    +  inject(result.toArray()).as('kv').select(values).
    +  unfold().
    +  map(unfold().as('v_or_e').
    +      coalesce(V().where(eq('v_or_e')).store('v'),
    +               select('v').tail(local, 1).bothE().where(eq('v_or_e'))).
    +      values('name','weight').
    +      fold()).
    +  group().
    +    by(select('kv').select(keys)).unfold().
    +  order().
    +    by(select(keys).select('from').id()).
    +    by(select(keys).select('to').id()).toList()
    +----
    +
    +<1> The side-effect `v` is used to keep track of the last processed 
vertex, hence it needs to be an order-preserving list. Without this explicit 
definition `v` would become a `BulkSet` which doesn't preserve the insert order.
    --- End diff --
    
    I was surprised that the elements didn't get dereferenced automatically 
(`result` contains `ReferencePath` objects holding `ReferenceVertex` and 
`ReferenceEdge` instances). If they were automatically reattached, the `map` 
step would be as simple as this:
    
    ```
      map(unfold().values('name','weight').fold())
    ```


---

Reply via email to