[
https://issues.apache.org/jira/browse/TINKERPOP-2491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18015064#comment-18015064
]
ASF GitHub Bot commented on TINKERPOP-2491:
-------------------------------------------
andreachild commented on code in PR #3184:
URL: https://github.com/apache/tinkerpop/pull/3184#discussion_r2287069052
##########
docs/src/upgrade/release-3.8.x.asciidoc:
##########
@@ -490,6 +490,52 @@ The `GremlinLangScriptEngine` has been modified to treat
float literals without
or 'd') as Double by default. Users who need `BigDecimal` precision can still
use the 'm' suffix (e.g., 1.0m).
`GremlinGroovyScriptEngine` will still default to `BigDecimal` for `float`
literals.
+==== Consistent Collection Output for range(), limit(), and tail() Local Steps
Review Comment:
Shortened to 'Consistent Output for range(), limit(), tail()'
> Improve consistency of the output of range() oriented steps
> -----------------------------------------------------------
>
> Key: TINKERPOP-2491
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2491
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
> Affects Versions: 3.4.9
> Reporter: Stephen Mallette
> Priority: Major
> Labels: breaking
>
> As pointed out here:
> https://groups.google.com/g/gremlin-users/c/OvxKvvM8rXs/m/slnv6cWpBQAJ
> there is an automatic {{List}} unfold with {{limit(local, 1)}} as in:
> {code}
> g.inject([1, 2, 3], [4]).limit(local, 3).toList() // [[1, 2, 3], [4]]
> g.inject([1, 2, 3], [4]).limit(local, 2).toList() // [[1, 2], [4]]
> g.inject([1, 2, 3], [4]).limit(local, 1).toList() // [1, 4] ??? - Expected
> [[1], [4]]
> g.inject([1, 2, 3], [4]).limit(local, 0).toList() // [[], []] oh come on
> {code}
> In addition, `range()` and `tail()` are similarly affected:
> {code}
> gremlin> g.inject([1, 2, 3], [4]).tail(local, 1).toList()
> ==>3
> ==>4
> gremlin> g.inject([1, 2, 3], [4]).range(local, 0, 1).toList()
> ==>1
> ==>4
> {code}
> Changing this is a fairly imposing breaking change in behavior. We could
> mitigate that with a strategy to support the old functionality if folks want
> to have that:
> {code}
> g.withStrategy(OldWayStrategy).inject([1, 2, 3], [4]).limit(local, 1)
> {code}
> would transform to:
> {code}
> g.inject([1, 2, 3], [4]).limit(local, 1).unfold()
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
