Cole-Greer commented on code in PR #3215:
URL: https://github.com/apache/tinkerpop/pull/3215#discussion_r2382927510
##########
docs/src/upgrade/release-3.8.x.asciidoc:
##########
@@ -888,6 +874,41 @@ pinned variable is one which must remain bound to the
current value. By paramete
variable, as it can be substituted in the optimized traversal without any loss
of meaning, however the variable "count"
will be pinned as the optimized traversal is not valid for other values of
"count".
+===== Decouple internal step state from `Configuring`/`Parameterizing`
interfaces
+
+Previously `AddVertexStep`, `AddVertexStartStep`, `AddEdgeStep`,
`AddEdgeStartStep`, and `AddPropertyStep` stored their
+internal state (id, label, properties, from/to vertices...) in a `Parameters`
object which was exposed via the
+`Configuring` and `Parameterizing` interfaces. These interfaces are primarily
intended to support with()-modulation, and
+thus these steps had weird unintended behaviors when combined with
with()-modulation:
+
+[source,text]
+----
+gremlin> g.addV().with("name", "cole").valueMap()
+==>[name:[cole]]
+----
+
+This internal step state has now been decoupled from the `Configuring` and
`Parameterizing` interfaces, which are now
+exclusively used for the purposes of with()-modulation. All accesses of these
steps internal data must now go through
Review Comment:
I will update with an explicit list of steps. It's primarily a concern for
strategy authors and providers as this is changing how data such as properties
is accessed from steps such as addV. The only users who will be impacted are
those doing silly things like using `with()` to set properties, which has never
been a documented or supported behaviour.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscr...@tinkerpop.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
