[
https://issues.apache.org/jira/browse/TINKERPOP-3261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18094441#comment-18094441
]
ASF GitHub Bot commented on TINKERPOP-3261:
-------------------------------------------
Cole-Greer commented on code in PR #3483:
URL: https://github.com/apache/tinkerpop/pull/3483#discussion_r3540395986
##########
docs/src/dev/developer/for-committers.asciidoc:
##########
@@ -672,8 +672,19 @@ TinkerGQL support out of the box and runs these scenarios
without any additional
* `@InsertionOrderingRequired` - The scenario is reliant on the graph system
predictably returning results (vertices,
edges, properties) in the same order in which they were inserted into the
graph.
* `@MetaProperties` - The scenario makes use of meta-properties.
+* `@MultiLabel` - The scenario requires a graph that supports multi-label
vertices (i.e.
+`ZERO_OR_MORE` vertex label cardinality). Providers that only support
single-label vertices should
+exclude these tests.
+* `@MultiLabelDefault` - The scenario expects multi-label output as the
default behavior for
Review Comment:
I've reworked the test infrastructure and updated these docs.
`@MultiLabelDefault` and `@SingleLabelDefault` are for providers to opt-out of
scenarios which assume the incorrect default behaviour for unconfigured
traversals in their graph. Every provider should opt-out of one of these 2 tags.
One noteworthy caveat is that we never run any of the `@MultiLabelDefault`
tests in TinkerGraph, as TinkerGraph does not have a configurable default here,
it is always a SingleLabelDefault graph. I think this is acceptable, as there
are relatively few tests using this tag, and I think we can just be careful
when reviewing those scenarios to ensure they properly encode the expected
semantics.
> 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)
