@@ -1414,8 +1414,8 @@ g.V().elementMap('name')
14141414g.V().dedup().by(label).values('name')
14151415----
14161416
1417- Finally, if `dedup()` is provided an array of strings, then it will ensure that the de-duplication is not with respect
1418- to the current traverser object, but to the path history of the traverser.
1417+ If `dedup()` is provided an array of strings, then it will ensure that the de-duplication is not with respect to the
1418+ current traverser object, but to the path history of the traverser.
14191419
14201420[gremlin-groovy,modern]
14211421----
@@ -1429,6 +1429,37 @@ g.V().as('a').both().as('b').both().as('c').
14291429<1> If the current `a` and `b` combination has been seen previously, then filter the traverser.
14301430<2> The "age" property is not <<by-step,productive>> for all vertices and therefore those values are filtered.
14311431
1432+ The `dedup()` step can work on many different types of objects. One object in particular can need a bit of explanation.
1433+ If you use `dedup()` on a `Path` object there is a chance that you may get some unexpected results. Consider the
1434+ following example which forcibly generates duplicate path results in the first traversal and in the second applies
1435+ `dedup()` to remove them:
1436+
1437+ [gremlin-groovy,modern]
1438+ ----
1439+ g.V().union(out().path(), out().path())
1440+ g.V().union(out().path(), out().path()).dedup()
1441+ ----
1442+
1443+ The `dedup()` step checks the equality of the paths by examining the equality of the objects on the `Path` (in this case
1444+ vertices), but also on any path labels. In the prior example, there weren't any path labels so `dedup()` behaved as
1445+ expected. In the next example, note the difference in the results if a label is added for one `Path` but not the other:
1446+
1447+ [gremlin-groovy,modern]
1448+ ----
1449+ g.V().union(out().as('x').path(), out().path())
1450+ g.V().union(out().as('x').path(), out().path()).dedup()
1451+ ----
1452+
1453+ The prior example shows how `dedup()` does not have the same effect when a path label is in place. In this contrived
1454+ example the answer is simple: remove the `as('x')`. If in the real world, it is not possible to remove the label, the
1455+ workaround is to deconstruct the `Path` into a `List` to drop the label. In this way, `dedup()` is just comparing `List`
1456+ objects and the objects in the `Path`.
1457+
1458+ [gremlin-groovy,modern]
1459+ ----
1460+ g.V().union(out().as('x').path(), out().path()).map(unfold().fold()).dedup()
1461+ ----
1462+
14321463*Additional References*
14331464
14341465link:++https://tinkerpop.apache.org/javadocs/x.y.z/core/org/apache/tinkerpop/gremlin/process/traversal/dsl/graph/GraphTraversal.html#dedup(org.apache.tinkerpop.gremlin.process.traversal.Scope,java.lang.String...)++[`dedup(Scope,String...)`],
@@ -5257,7 +5288,7 @@ First, it is important to recognize that there is a bit of a difference in behav
52575288becomes its composite `Map.Entry` objects as is typical in Java. The following example demonstrates the basic name/value
52585289pairs that returned:
52595290
5260- [groovy,modern]
5291+ [gremlin- groovy,modern]
52615292----
52625293g.V().valueMap('name','age').unfold()
52635294----
@@ -5312,7 +5343,7 @@ Display stack trace? [yN]
53125343While this problem might be solved in future versions, the workaround for both cases is to use
53135344<<constant-step,constant()>> as shown in the following example:
53145345
5315- [groovy,modern]
5346+ [gremlin- groovy,modern]
53165347----
53175348g.V().hasLabel('person').both().group().by(constant(id))
53185349g.V().hasLabel('person').both().group().by('age').select(constant(32))
0 commit comments