You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tinkerpop.apache.org by "Matthias Broecheler (JIRA)" <ji...@apache.org> on 2015/04/10 22:00:12 UTC

[jira] [Created] (TINKERPOP3-627) Default VertexProperty Cardinality

Matthias Broecheler created TINKERPOP3-627:
----------------------------------------------

             Summary: Default VertexProperty Cardinality
                 Key: TINKERPOP3-627
                 URL: https://issues.apache.org/jira/browse/TINKERPOP3-627
             Project: TinkerPop 3
          Issue Type: Improvement
          Components: structure
            Reporter: Matthias Broecheler
             Fix For: 3.0.0.GA


There are two property setters on vertex that don't take a cardinality argument:
{code:java}
    public default <V> VertexProperty<V> property(final String key, final V value) {
        return this.property(VertexProperty.Cardinality.single, key, value);
    }

    public default <V> VertexProperty<V> property(final String key, final V value, final Object... keyValues) {
        return this.property(VertexProperty.Cardinality.single, key, value, keyValues);
    }
{code}

Both of these default the cardinality to {{single}}. That's unfortunate for database implementations with an explicit schema since the cardinality of the key is defined in there. For instance, a user can define that a property key {{name}} is a multi-property. However if they then do {{v.property('names','Marko')}} it will default to cardinality single at which point the database vendor has the option of a) throwing an exception or b) deleting all other names and adding 'Marko' (i.e. the semantics of 'single'). The first one is annoying and the latter is very confusing.

I would propose that TinkerPop does not prescribe what the default should be and leave that up to the vendor. In its test cases it should specify the cardinality explicitly always and to test the above two methods it should only test if the value appears (i.e. don't test the cardinality).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)