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

["Matt Frantz (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/TINKERPOP3-627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14490488#comment-14490488 ] 

Matt Frantz commented on TINKERPOP3-627:
----------------------------------------

One of the huge advantages of TinkerPop is vendor agnosticism.  Does this issue only arise if a user goes outside of TinkerPop to specify the database schema, essentially voiding the TinkerPop API contract?  Is there a way to incorporate the database declaration into TinkerPop so that property cardinality could be discoverable or even configurable through TinkerPop?  Maybe something like this:

{noformat}
g.schema().verticesWithLabel('foo').propertyCardinality('bar', Cardinality.single);
{noformat}


> 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)