@Bryn, that's an interesting idea. There is also the chance that it would encourage users to give plural property keys to properties that might contain multiple values, which I think would be a good practice.
As for the original question, my preference for default is Cardinality.single. Bob On Mon, Mar 23, 2015 at 7:40 AM, Bryn Cooke <[email protected]> wrote: > Hi > I have always been uneasy with the asymmetry of the property methods in > TP3, > > vertex.property('name', "stephen") //Sets the property to a string > vertex.property('name') //Returns an object of type VertexProperty :-( > > How about this? It should feel more natural to Java devs as "add" is the > method we expect on collections. > > vertex.property('name').add('stephen') //Add (list/set) > vertex.property('name').set('stephen') //Set a single value > > It is then up to the graph schema (if supported) to deal with the add > method and if it is a list or set. > > Or alternatively: > > vertex.property('name').add('stephen') // add a new name property to > vertex -- ignoring whether a name property already exists. > vertex.property('name').put('stephen') // if the name 'stephen' already > exists, do not add a new property > vertex.property('name').set('stephen') // if a property of name already > exists, delete it and add stephen. > > Bryn > > > On 20/03/15 17:14, Matt Frantz wrote: > >> My preference: Cardinality.single >> >> Since property values can be arbitrary types (subject to vendor >> restrictions), I consider the alternate cardinalities to be sugar, albeit >> admittedly convenient shorthand when updating existing collection-valued >> properties. >> >> Slight tangent: It would be nice to see some type extensibility here. >> For example, if you want a property to have a histogram, then you could >> register a histogram type with an appropriate Java interface, or with a >> lambda that describes what happens when a value is added, analogous to the >> withSack API. Graph vendors could add value by providing a set of property >> types that have good performance characteristics. >> >> On Friday, March 20, 2015 at 9:13:13 AM UTC-7, Marko A. Rodriguez wrote: >> >> Hello, >> >> In TinkerPop3, vertices can have multi-properties of the same key. >> These are called "vertex properties." >> >> http://tinkerpop.incubator.apache.org/docs/3.0.0- >> SNAPSHOT/#vertex-properties >> <http://tinkerpop.incubator.apache.org/docs/3.0.0- >> SNAPSHOT/#vertex-properties> >> >> When you create a VertexProperty, you can provide a cardinality. >> For instance: >> >> vertex.property(single,'name','stephen') // if a property of name >> already exists, delete it and add stephen. >> vertex.property(list,'name','stephen') // add a new name property >> to vertex -- ignoring whether a name property already exists. >> vertex.property(set,'name','stephen') // if the name 'stephen' >> already exists, do not add a new property >> >> The question is -- what is: >> >> vertex.property('name','stephen') >> >> In other words, the default behavior. Right now, its >> Cardinality.list. However, many people have stated that they would >> like it to be Cardinality.single and thus, more aligned with >> TinkerPop2 and most graph database vendors. >> >> This is something we will want to have down by TP3 GA -- so please >> voice your thoughts. >> >> Thank you, >> Marko. >> >> http://markorodriguez.com >> >> >
