About done with this change for 3.7.0:
https://github.com/apache/tinkerpop/pull/2127
I think we should consider deprecating:
property(Cardinality, String, Object, Object...)
in favor of the direct use of Cardinality.list(Object) as part of setting
the value. so, like:
property(list, 'color', 'red')
would become:
property('color', list(red))
in that way we would have consistency between the property() and mergeV().
Also, I'd also like to consider moving VertexProperty.Cardinality in java
to it's own file so that it can just be referenced as Cardinality. If
there's no concerns brought up to either of these items here, I'll create
the necessary JIRAs for future versions.
On Mon, Jun 26, 2023 at 10:58 AM Stephen Mallette <spmalle...@gmail.com>
wrote:
> I pushed a branch here for this change:
>
> https://github.com/apache/tinkerpop/tree/TINKERPOP-2957
>
> it crossed over into property(Map) a bit so i tried to make that
> consistent too. i'd really like if the variants could have a syntax more
> like java, but java seems to be the only one that allows methods on enums
> to work in the fashion of the grammar syntax. anyway, if there are no other
> ideas on how to do that, i'll document the various differences for the
> variants and issue the PR.
>
>
>
> On Fri, Jun 16, 2023 at 2:00 PM Stephen Mallette <spmalle...@gmail.com>
> wrote:
>
>> Kelvin opened this one a while back:
>>
>> https://issues.apache.org/jira/browse/TINKERPOP-2957
>>
>> I'd like to suggest this syntax to resolve the issue of Cardinality
>> specification with mergeV():
>>
>> // current approach to set cardinality
>> g.mergeV([firstname:"john",lastname:"handcock"]).
>> option(Merge.onMatch,sideEffect(property(single,"firstname","james"),
>>
>> property(single,"lastname","madison")).constant([:]))
>>
>> // current syntax will just use default cardinality for the underlying
>> graph
>> g.mergeV(["firstname":"firstname"]).
>> option(Merge.onMatch, [firstname:"james",lastname:"madison"])
>>
>> // revised syntax provide cardinality override per property where
>> firstname will be explicitly
>> // single but lastname will be the default for the underlying graph. the
>> `Cardinality.single()`
>> // a static method on Cardinality produces a CardinalityValue object
>> which will have
>> // special meaning to the MergeVStep
>> g.mergeV([firstname:"john",lastname:"handcock"]).
>> option(Merge.onMatch, [firstname:single("james"),lastname:"madison"])
>>
>> // revised syntax to provide cardinality for all properties onMatch where
>> both firstname
>> // and lastname will be set explicitly to single
>> g.mergeV(["firstname":"firstname"]).
>> option(Merge.onMatch, [firstname:"james",lastname:"madison"], single)
>>
>>
>> // the above translates to the following so the user won't have to add
>> single to each property
>> g.mergeV([firstname:"john",lastname:"handcock"]).
>> option(Merge.onMatch,
>> [firstname:single("james"),lastname:single("madison")])
>>
>>
>>
