[
https://issues.apache.org/jira/browse/TINKERPOP-3244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18077759#comment-18077759
]
ASF GitHub Bot commented on TINKERPOP-3244:
-------------------------------------------
L0Lmaker opened a new pull request, #3416:
URL: https://github.com/apache/tinkerpop/pull/3416
## Summary
- Adds `Traversal.NextN(n int) ([]*Result, error)` to gremlin-go for batched
result iteration, providing API parity with `next(n)` in the Java, Python, and
.NET GLVs.
- Behavior matches the Java reference (`Traversal.java:107`): returns up to
`n` results, returns what is available if fewer exist, returns an empty slice
for `n <= 0`, and surfaces `ResultSet` errors.
- Method name is `NextN` rather than `Next(n int)` because Go does not
support method overloading — a literal port of the Java signature would collide
with the existing `Next() (*Result, error)`. This matches the existing pattern
in gremlin-go where overloaded Java APIs are split into distinctly-named Go
methods (e.g. `ResultSet.One()` vs `ResultSet.All()`).
## JIRA
[TINKERPOP-3244](https://issues.apache.org/jira/browse/TINKERPOP-3244)
## Backport question for maintainers
The JIRA lists Affects Versions `3.7.5, 3.8.1`. Per the PR template I would
normally target the earliest branch and let it merge forward, but the iteration
model in gremlin-go diverged on master (`GremlinLang` + `nextValue()` helper)
vs `3.7-dev` / `3.8-dev` (`Bytecode` + `One()` directly). The implementation
here is master-shaped and won't forward-merge cleanly without a rewrite for the
older protocol.
Targeting `master` for now. **Please let me know your preference** — happy
to open companion PRs against `3.7-dev` and `3.8-dev` with implementations
matching their respective iteration models if that is how you would like it
landed.
## Test plan
- [x] `go build ./...` clean
- [x] `go vet ./driver/` clean
- [x] `gofmt` clean
- [x] 9 new unit tests in `TestTraversalNextN` cover: `n < available`, `n ==
available`, `n > available`, `n = 0`, `n < 0`, exhausted traversal, bulked
traverser unrolling across batch boundary, repeated drain calls, error
propagation
- [x] Existing tests (`TestTraversalNextValue`,
`TestTraversal/Test_clone_traversal`,
`TestTraversal/Test_Iterate_with_empty_removeConnection`) still pass
- [x] Full integration suite via `./run.sh 4.0.0-beta.2`: 2017/2043 cucumber
scenarios pass, all gremlin-go tests including `TestTraversalNextN` pass. The
single failing scenario (`g_injectXnull_nullX_conjoinXplusX`) is unrelated to
this change — pre-existing client/server version skew where the master client
expects the post-TINKERPOP-3225 server fix that is not in the published
`4.0.0-beta.2` server image.
## Notes
This change was AI-assisted; the commit includes the `Assisted-by:` trailer
per `AGENTS.md`.
> Add next(n) batch iteration to gremlin-go for GLV parity
> --------------------------------------------------------
>
> Key: TINKERPOP-3244
> URL: https://issues.apache.org/jira/browse/TINKERPOP-3244
> Project: TinkerPop
> Issue Type: Improvement
> Components: driver
> Affects Versions: 3.7.5, 3.8.1
> Reporter: Taylor Riggan
> Priority: Minor
>
> The Java, Python, and .NET GLVs all support `next\(n\)` on Traversal to
> retrieve multiple results at once, but gremlin-go only supports single-item
> `Next()` returning `(*Result, error)`. This creates an API inconsistency
> across GLVs that makes it harder to write portable examples and documentation.
> Currently, users must manually collect results from `GetResultSet()` +
> `One()` in a loop to achieve the same behavior. A `Next(n int) ([]*Result,
> error)` method on `Traversal` would bring gremlin-go in line with the other
> GLVs.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
