[
https://issues.apache.org/jira/browse/TINKERPOP-3261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18092395#comment-18092395
]
ASF GitHub Bot commented on TINKERPOP-3261:
-------------------------------------------
spmallette commented on code in PR #3483:
URL: https://github.com/apache/tinkerpop/pull/3483#discussion_r3494081188
##########
docs/src/reference/implementations-tinkergraph.asciidoc:
##########
@@ -166,6 +166,7 @@ TinkerGraph has several settings that can be provided on
creation via `Configura
|gremlin.tinkergraph.vertexPropertyIdManager |The `IdManager` implementation
to use for vertex properties.
|gremlin.tinkergraph.defaultVertexPropertyCardinality |The default
`VertexProperty.Cardinality` to use when `Vertex.property(k,v)` is called.
|gremlin.tinkergraph.allowNullPropertyValues |A boolean value that determines
whether or not `null` property values are allowed and defaults to `false`.
+|gremlin.tinkergraph.vertexLabelCardinality |The `LabelCardinality` for
vertices. Options are `ONE` (default, single immutable label,
backward-compatible with 3.x), `ONE_OR_MORE` (at least one label, mutable), or
`ZERO_OR_MORE` (fully flexible, zero or more labels). See
<<tinkergraph-multi-label>>.
Review Comment:
"fully flexible" is an odd description to me. just "zero or more labels"
seems right.
> Enable multiple label support on vertex with configurable label cardinality
> ---------------------------------------------------------------------------
>
> Key: TINKERPOP-3261
> URL: https://issues.apache.org/jira/browse/TINKERPOP-3261
> Project: TinkerPop
> Issue Type: Task
> Affects Versions: 4.0.0
> Reporter: Yang Xia
> Priority: Major
>
> Vertices are currently limited to a single immutable label assigned at
> creation. This prevents modeling common real-world scenarios where entities
> naturally belong to multiple categories (e.g., a person who is both an
> employee and a manager).
>
> Introduce a configurable LabelCardinality that controls how many labels a
> vertex may have and whether they can be mutated after creation. Three
> proposed modes: ONE (current behavior, default), ONE_OR_MORE (mutable,
> minimum one), ZERO_OR_MORE (fully flexible).
>
> New steps:
>
> - labels() — flatMap step emitting each label as a traverser
> - addLabel(String, String...) — add labels to a vertex
> - dropLabel(String, String...) — remove specific labels
> - dropLabels() — remove all labels
> Edge labels remain at cardinality ONE. The infrastructure would support
> future edge multi-label enablement without wire format changes.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
