Cole-Greer commented on code in PR #3523:
URL: https://github.com/apache/tinkerpop/pull/3523#discussion_r3606163636
##########
docs/src/upgrade/release-4.x.x.asciidoc:
##########
@@ -1094,33 +1066,16 @@ expected for the 4.0.0 major release.
===== Multi-Label Support
-Providers declare their supported label cardinality via
`Graph.Features.getLabelCardinality()`, which defaults to
-`LabelCardinality.ONE` (single label, immutable, the 3.x behavior). To support
multi-label, return `ONE_OR_MORE` or
-`ZERO_OR_MORE` from this method. This value may be a static constant for a
graphs which do not offer configurable label
-cardinality. The label cardinality should reflect the current `Graph` instance.
-
-The `LabelCardinality` enum exposes `min()`, `max()`, and `supportsMutation()`
for programmatic introspection of
-constraints. Constraint enforcement is handled by the
`LabelCardinalityValidator` utility class, which providers may
-use directly or replace with their own validation logic tailored to their
storage backend.
-
-Providers implementing multi-label must:
-
-- Store and return a `Set<String>` from `Element.labels()`
-- Implement `Element.addLabel(String, String...)` and
`Element.dropLabel(String, String...)`
-- Ensure `hasLabel("a", "b")` uses OR semantics (matches vertices with label
"a" or "b")
-- Serialize/deserialize the label set via the V4 GraphBinary format (which
sends labels as a list)
-
-The default `elementMap()` and `valueMap()` implementations determine label
output format solely from the
-`with("multilabel")` source option, not from the graph's `LabelCardinality`.
This means a multi-label graph still
-returns a single label string from these steps unless `with("multilabel")` is
explicitly configured. The intent is
-to eventually deprecate the single-string path entirely and always return
labels as a set, aligning `elementMap()`
-and `valueMap()` with `labels()`. Until then, `with("singlelabel")` allows
users to override a source-level
-`with("multilabel")` back to single-string output.
-
-Providers who want `elementMap()`/`valueMap()` to return the full label set by
default (without requiring users to
-set `with("multilabel")`) should override `PropertyMapStep` and
`ElementMapStep` to tie label output to their
-server-side label cardinality configuration. In that case,
`with("singlelabel")` should still be respected as an
-explicit user override back to single-string output.
+Providers declare their supported label cardinality via
`Graph.Features.VertexFeatures#getLabelCardinality()`, which
Review Comment:
Could use more sensitivity around the concept of "default".
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]