Sorry to be dredging up some old business with respect to the settled issue
of the default cardinatlity of property(k,v) which we some time ago voted
to leave up to vendors. We further decided to make sure that in the tests
we always called property(cardinality, k, v) and use features to
appropriately filter the test suite when executed by vendors.
What that didn't address was how we internally utilize property(k,v) within
gremlin-core. The core example here would be with IO where we want to
provide internal "getOrCreate" functionality. What should that
"getOrCreate" do on create for properties? If we were to explicitly call:
property(list, k, v)
as we do in tests, and the graph didn't support it, there might be a
problem. alternatively, if a graph did support it, and the user wanted it
to execute as "single", then that would be a problem too.
There's lots of discussion rabbit holes to go down here, but ultimately I
think that we can honor the previous vote and support what we want if we
implement a suggestion from Marko:
public default Property property(k,v) {
return supportsMultiProperties ? property(list, k, v) : property(single,
k, v)
}
then internally (within gremlin-core) we always use property(k,v) to set a
property (tests will continue to use explicit cardinality since that's
already working with feature checks). Vendors can choose to override this
method as needed, with the understanding that internal calls from
gremlin-core will use it for defaults.
For the user:
1. They should consult their vendor implementation for their default
operations in this area.
2. They should feature check their own code to be vendor agnostic.
3. They can avoid gremlin internals as needed and use supply their own
getOrCreate functions thus allowing a finer degree of control (e.g. maybe
one property key is to be loaded as list but all others should be single.
If anyone has any thoughts or better ways to settle this, please let me
know.
Thanks,
Stephen
