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]

Reply via email to