Skip to content

Commit a4a506d

Browse files
committed
TINKERPOP-2886 Added docs to workaround dedup() path issues CTR
1 parent 755778a commit a4a506d

File tree

1 file changed

+35
-4
lines changed

1 file changed

+35
-4
lines changed

docs/src/reference/the-traversal.asciidoc

Lines changed: 35 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -1414,8 +1414,8 @@ g.V().elementMap('name')
14141414
g.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
14341465
link:++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
52575288
becomes its composite `Map.Entry` objects as is typical in Java. The following example demonstrates the basic name/value
52585289
pairs that returned:
52595290
5260-
[groovy,modern]
5291+
[gremlin-groovy,modern]
52615292
----
52625293
g.V().valueMap('name','age').unfold()
52635294
----
@@ -5312,7 +5343,7 @@ Display stack trace? [yN]
53125343
While 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
----
53175348
g.V().hasLabel('person').both().group().by(constant(id))
53185349
g.V().hasLabel('person').both().group().by('age').select(constant(32))

0 commit comments

Comments
 (0)