[
https://issues.apache.org/jira/browse/TINKERPOP-1522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16378846#comment-16378846
]
ASF GitHub Bot commented on TINKERPOP-1522:
-------------------------------------------
GitHub user dkuppitz opened a pull request:
https://github.com/apache/tinkerpop/pull/803
TINKERPOP-1522 Order of select() scopes
https://issues.apache.org/jira/browse/TINKERPOP-1522
This PR changes the order of `select()` scope from
* side-effects, maps, paths
to
* maps, side-effects, paths
`docker/build.sh -t -i` passed.
Note that I discovered a bug in OLAP while writing the test case, that's
why there is an extra `barrier()` step. I'll create another ticket to address
this issue.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/apache/tinkerpop TINKERPOP-1522
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/tinkerpop/pull/803.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #803
----
commit 5bb8ca3556e5582f11e19a00925b8a149f97a1ee
Author: Daniel Kuppitz <daniel_kuppitz@...>
Date: 2018-02-21T20:52:53Z
Changed order of `select()` scopes. Maps (local objects) come firstm then
side-effects, then paths.
commit 04674f1eed46574351dfb0a8db6bd8d4eb1136f1
Author: Daniel Kuppitz <daniel_kuppitz@...>
Date: 2018-02-26T18:19:21Z
added new test case to verify new select scope order
commit 1316b09b1388e2ffb707545a6378534747cec77a
Author: Daniel Kuppitz <daniel_kuppitz@...>
Date: 2018-02-27T15:49:17Z
updated CHANGELOG
----
> Order of select() scopes
> ------------------------
>
> Key: TINKERPOP-1522
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1522
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
> Affects Versions: 3.2.3
> Reporter: Daniel Kuppitz
> Assignee: Daniel Kuppitz
> Priority: Major
> Labels: breaking
>
> As it currently stands, side-effects have the highest priority when a key is
> {{select()}}'ed. I just ran into a problem where this behavior was more than
> disadvantageous:
> {code}
> gremlin> g = TinkerGraph.open().traversal()
> ==>graphtraversalsource[tinkergraph[vertices:0 edges:0], standard]
> gremlin> g.withSideEffect("a", ["a":
> "marko"]).inject(1).select("a").select("a") // expected result is "marko",
> not "[a:marko]"
> ==>[a:marko]
> {code}
> In my use-case the map keys were not predictable, hence it's almost
> impossible to prevent a key name collision. IMO maps (and paths) should take
> precedence over side-effects.
> It is still possible to get the nested {{a}} key, but I'm pretty sure that
> the common Gremlin user won't be able to come up with this query:
> {code}
> gremlin> g.withSideEffect("a", ["a": "marko"]).inject(1).select("a").
> map(unfold().filter(select(keys).is("a")).select(values))
> ==>marko
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
