[
https://issues.apache.org/jira/browse/TINKERPOP-3261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18091691#comment-18091691
]
ASF GitHub Bot commented on TINKERPOP-3261:
-------------------------------------------
xiazcy opened a new pull request, #3483:
URL: https://github.com/apache/tinkerpop/pull/3483
Introduces configurable label cardinality for graph elements. Vertex
cardinality is user-configurable; edge cardinality defaults to ONE and is not
yet exposed as a configuration option but uses the same underlying
infrastructure.
Vertices can now have zero, one, or many labels controlled by
LabelCardinality (defaults to ONE for full backward compatibility). New
traversal steps labels(), addLabel(), dropLabel(), and dropLabels() enable
label retrieval and mutation. Edge labels remain fixed at cardinality ONE.
Notes on design:
- LabelCardinality is a pure data descriptor enum with min()/max()/mutable
fields. Validation logic lives in a separate LabelCardinalityValidator utility.
- mergeV() uses append-only semantics for onMatch labels (no implicit
replacement).
- hasLabel('a','b') is OR semantics, use hasLabel('a').hasLabel('b') for AND
semantics.
- with("multilabel") is source-level setting for backwards compatibility.
Configures elementMap()/valueMap() to return labels as a Set instead of a
single String by default.
- Older serialization formats (GraphSON V1/V2/V3, Gryo) silently use label()
which returns one non-deterministic label. Only GraphBinary and GraphSON V4
preserve the full label set.
Commits:
1. Vertex prototype: labels() step, addLabel/dropLabel steps,
Element.labels() API, TinkerGraph implementation
2. Edge API surface: edge label overrides (validate-and-throw for ONE),
transaction fix, feature tests
3. GLV implementations: .NET, Go, JavaScript, Python support
4. Cardinality + with('multilabel'): LabelCardinality enum,
LabelCardinalityValidator, append-only merge, source-level config
5. Defaults, strategy, docs, tests: TinkerGraph ONE default,
LabelsDropVerificationStrategy, reference/upgrade/provider docs, CHANGELOG
Configuration
To Enable multi-label in TinkerGraph:
gremlin.tinkergraph.vertexLabelCardinality=ZERO_OR_MORE
Testing
- Feature tests (Gherkin): Labels.feature, AddLabel.feature,
DropLabel.feature, MergeVertex multi-label scenarios
- Unit tests: LabelMutationStepTest, LabelCardinalityTest,
LabelReplacePatternValidationTest, hasLabel OR/AND semantics
---
VOTE +1
> 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)
