[
https://issues.apache.org/jira/browse/TINKERPOP-2198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP-2198:
----------------------------------------
Affects Version/s: 3.3.6
Component/s: process
documentation
Thanks for reporting this. [~dkuppitz] determined that {{EarlyLImitStrategy}}
"fixed" {{store()}} so that's why that sentence doesn't seem to apply anymore.
I sorta like that output better, but it's "bad" that a strategy is responsible
for that happening. Not sure what the solution should be.
> Documentation for Store contradicts itself
> ------------------------------------------
>
> Key: TINKERPOP-2198
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2198
> Project: TinkerPop
> Issue Type: Bug
> Components: documentation, process
> Affects Versions: 3.3.6
> Reporter: Martijn Dwars
> Priority: Minor
>
> The [Store
> Step|http://tinkerpop.apache.org/docs/current/reference/#store-step] shows
> the following example:
> {{gremlin> g.V().store('x').limit(1).cap('x')}}
> {{==>[v[1]]}}
>
> and continues with the following explanation:
>
> {quote}It is interesting to note that there are two results in the
> {{store()}} side-effect even though the interval selection is for 1 object.
> Realize that when the second object is on its way to the {{range()}} filter
> (i.e. {{[0..1]}}), it passes through {{store()}} and thus, stored before
> filtered.
> {quote}
> The problem is that the example does _not_ show this lazy behavior. The
> correct output would be:
> {{==>[v[1], v[2]]}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
