As a user, I'd prefer any vendor-specific behavior other than performance to be explicit in the API. For example, the strategies API is a good example, since a vendor can declare the strategies they support, and attempting to use an unsupported strategy produces a runtime error at an intuitive code location.
For something like this, i.e. the default functional behavior of a step, I'd prefer that vendor-specific behaviors be easier to avoid and more explicit, or to be eliminated entirely, in this case, either by eliminating the default cardinality API or specifying its behavior. I understand that I CAN use a portable API in this case, but I want to make it so that I MUST use a portable API. An alternative would be to split GraphTraversal into PortableGraphTraversal and VendorSpecificGraphTraversal. Another alternative would be to annotate the GraphTraversal methods in such a way that I could "lint" my code to make sure I use only portable methods. On Fri, May 1, 2015 at 5:14 AM, Stephen Mallette <[email protected]> wrote: > 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 >
