[
https://issues.apache.org/jira/browse/TINKERPOP-2198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette closed TINKERPOP-2198.
---------------------------------------
Resolution: Fixed
Assignee: stephen mallette
Fix Version/s: 3.4.2
3.3.7
Updated the documentation to reflect the effect of {{EarlyLimitStrategy}}:
https://github.com/apache/tinkerpop/commit/783eb0758fe5ae3fc9804438cb641bab9b4efc84
> 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
> Assignee: stephen mallette
> Priority: Minor
> Fix For: 3.3.7, 3.4.2
>
>
> 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)
