[jira] [Commented] (TINKERPOP3-612) Support only two types of Cardinality -- SINGLE and MULTI

["Matthias Broecheler (JIRA)" <ji...@apache.org>]

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

Matthias Broecheler commented on TINKERPOP3-612:
------------------------------------------------

+1 on simplifying this to single and multi. This would still allow vendors to implement set cardinality as a special case of multi. For instance, Luca hinted at OrientDB explicitly supporting this. This could be accommodated by declaring set behavior in the schema for the key which then gives some uniqueness guarantees. In general, vendors could go crazy on what kind of uniqueness or constraint enforcement they want to allow for multi properties (e.g. multiple properties can have the same value but if their timestamp is identical they overwrite). Modeling all such scenarios in TinkerPop would be out of scope I would think.

> Support only two types of Cardinality -- SINGLE and MULTI
> ---------------------------------------------------------
>
>                 Key: TINKERPOP3-612
>                 URL: https://issues.apache.org/jira/browse/TINKERPOP3-612
>             Project: TinkerPop 3
>          Issue Type: Improvement
>          Components: structure
>            Reporter: Marko A. Rodriguez
>            Assignee: Marko A. Rodriguez
>             Fix For: 3.0.0.GA
>
>
> We currently support the following {{Cardinality}} states:
> * {{single}}: one property per property key.
> * {{list}}: any number of properties per property key.
> * {{set}}: multi properties for the property key if and only if the values are unique.
> Right now equality for {{set}} is determined by {{Object.equals}}. This may be sufficient for most users, but maybe not. Next, this is an expensive operation for vendors that don't index on value. Finally, it seems to be of limited use in practice due to its complex behavior regarding meta-property overwriting. I think its best to NOT include {{set}} as an option -- simplifies the API and is more aligned with the core semantics of:
> * {{single}}
> * {{multi}}



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