Skip to content

Conversation

@xiazcy
Copy link
Contributor

@xiazcy xiazcy commented Oct 7, 2025

Added deprecation for the removal of Scope in aggregate() in 3.8-dev, which is a follow-up to the Lazy vs Eager evaluation proposal. Duplicated existing aggregate(local, 'x') and store() tests with local(aggregate('x')) forms to ensure they are semantically equivalent.

… features tests for the preferred usage of `local(aggregate(String))`.
=== TinkerPop 3.7.5 (Release Date: NOT OFFICIALLY RELEASED YET)
* Improved Java driver host availability on connection pool initialization.
* Deprecate `AggregateLocalStep` and `aggregate(Scope, String)`.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* Deprecate `AggregateLocalStep` and `aggregate(Scope, String)`.
* Deprecated `AggregateLocalStep` and `aggregate(Scope, String)`.

[source,text]
----
// 3.7.4
gremlin> g.V().aggregate(Scope.local, "x").by("age").cap("x")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if this is the best example, as cap() only produces the last output so regardless of eager or lazy evaluation, the result should be the same. Maybe use select() instead instead cap().

Given the modern graph
And the traversal of
"""
g.V().local(aggregate("a").by("name")).out().cap("a")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same coment before about cap() vs select().

==== Deprecation of Scopes in aggregate() Step
Scopes are now deprecated inside the `aggregate()` step, and will be removed in the next major upgrade.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Scopes are now deprecated inside the `aggregate()` step, and will be removed in the next major upgrade.
The acceptance of a scope parameter is now deprecated for the `aggregate()` step, and will be removed in the next major upgrade.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The suggestion has the right idea, but it should be "The acceptance of a Scope parameter to aggregate() step is now deprecated, and will be removed in the next major upgrade.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would be good to further include some tie in to store which is already deprecated:

This deprecation, in combination with the deprecation of store in x.x.x, will help users begin to consider the implications of their usage of these steps as it pertains to lazy versus eager flow control by converting to more explicit Gremlin patterns that have more consistent and intuitive semantics.

That sentence can help lead into more details of those patterns and reasons "why" which @andreachild asked for.

==== Deprecation of Scopes in aggregate() Step
Scopes are now deprecated inside the `aggregate()` step, and will be removed in the next major upgrade.
The preferred way to achieve lazy evaluation with `aggregate()`, is using `local()`.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please explain why this was done? Can reference the proposal if that helps.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it fine to reference the proposal, but it is dense and no one will read it. A good summary explanation as to the "why", with examples that clarify, is necessary imo.

Comment on lines +40 to +46
// 3.7.4
gremlin> g.V().aggregate(Scope.local, "x").by("age").cap("x")
==>[29,27,32,35]
// 3.7.5 convention
gremlin> g.V().local(aggregate("x").by("age")).cap("x")
==>[29,27,32,35]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
// 3.7.4
gremlin> g.V().aggregate(Scope.local, "x").by("age").cap("x")
==>[29,27,32,35]
// 3.7.5 convention
gremlin> g.V().local(aggregate("x").by("age")).cap("x")
==>[29,27,32,35]
// 3.7.5 deprecated
gremlin> g.V().aggregate(Scope.local, "x").by("age").cap("x")
==>[29,27,32,35]
// 3.7.5 recommended
gremlin> g.V().local(aggregate("x").by("age")).cap("x")
==>[29,27,32,35]


/**
* @see GraphTraversal#aggregate(Scope, String)
* @deprecated As of release 3.7.5, aggregate() is no longer scoped, to achieve lazy evaluation use local() with aggregate() instead
Copy link
Contributor

@andreachild andreachild Oct 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested rewording, same for all similar comments

Suggested change
* @deprecated As of release 3.7.5, aggregate() is no longer scoped, to achieve lazy evaluation use local() with aggregate() instead
* @deprecated As of release 3.7.5, aggregate() with scope parameter is deprecated - to achieve lazy evaluation use local() with aggregate() instead

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i think you could go even shorter because the deprecation comment clearly applies to the Scope argument.

@deprecated As of release 3.7.5, prefer a pattern with {@link local()} and {@link aggregate()} instead

obviously, those links need fixup, but that's the idea.

// An associative array containing the scenario name as key, for example:
'g_withSideEffectXa_setX_V_both_name_storeXaX_capXaX': new IgnoreError(ignoreReason.setNotSupported),
'g_withSideEffectXa_setX_V_both_name_aggregateXlocal_aX_capXaX': new IgnoreError(ignoreReason.setNotSupported),
'g_withSideEffectXa_setX_V_both_name_localXaggregateX_aXX_capXaX': new IgnoreError(ignoreReason.setNotSupported),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you please add a comment as to why this is not supported?

And using the parameter vid1 defined as "v[marko].id"
And the traversal of
"""
g.V(vid1).store("a").by("name").out().local(aggregate("a").by("name")).values("name").cap("a")
Copy link
Contributor

@andreachild andreachild Oct 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should new tests for store be avoided since it is deprecated?

Given the modern graph
And the traversal of
"""
g.V().local(aggregate("a").by("name")).out().cap("a")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Curious why this was added to the Store.feature if it doesn't use the store step?

* @since 3.4.3
* @deprecated As of release 3.7.5, aggregate() is no longer scoped, to achieve lazy evaluation use aggregate() inside of local()
*/
public default GraphTraversal<S, E> aggregate(final Scope scope, final String sideEffectKey) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
public default GraphTraversal<S, E> aggregate(final Scope scope, final String sideEffectKey) {
@Deprecated
public default GraphTraversal<S, E> aggregate(final Scope scope, final String sideEffectKey) {

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is a similar change needed to GraphTraversal.cs?

@Cole-Greer
Copy link
Contributor

VOTE +1 pending resolution of above comments

=== Upgrading for Users
==== Deprecation of Scopes in aggregate() Step
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"Scopes" really isn't the right term here. Also, the sections can't be too long or they wrap terribly in the ToC. How about just "Deprecate aggregate(Scope)`?

* @see GraphTraversal#aggregate(Scope, String)
* @deprecated As of release 3.7.5, aggregate() is no longer scoped, to achieve lazy evaluation use local() with aggregate() instead
*/
public static <A> GraphTraversal<A, A> aggregate(final Scope scope, final String sideEffectKey) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

need a @Deprecated annotation?

* @return the traversal with an appended {@link AggregateGlobalStep}
* @see <a href="http://tinkerpop.apache.org/docs/${project.version}/reference/#aggregate-step" target="_blank">Reference Documentation - Aggregate Step</a>
* @since 3.4.3
* @deprecated As of release 3.7.5, aggregate() is no longer scoped, to achieve lazy evaluation use aggregate() inside of local()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

adjust deprecation comment as noted with the __ class.


/**
* @author Marko A. Rodriguez (http://markorodriguez.com)
* @deprecated As of release 3.7.5, use local() with aggregate() instead
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

a bit of a nit i gues, but I think in this case, the deprecation comment is:

@deprecated As of release 3.7.5, not replaced

As a Gremlin step implementation, it's just gone...there's no direct replacement for usage. GraphTraversal and __ as user facing get the slightly fancier message.

@xiazcy
Copy link
Contributor Author

xiazcy commented Oct 27, 2025

Closing this PR, as we are no longer deprecating the steps in 3.7 due to local semantics changes (#3246) that will result in slightly altered behavior, and will make the removal in 3.8 a clean break.

@xiazcy xiazcy closed this Oct 27, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants