You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tinkerpop.apache.org by "stephen mallette (JIRA)" <ji...@apache.org> on 2015/04/07 17:34:15 UTC

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

     [ https://issues.apache.org/jira/browse/TINKERPOP3-612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

stephen mallette updated TINKERPOP3-612:
----------------------------------------
    Affects Version/s:     (was: 3.0.0.GA)

For the reasons given, I think i'm +1 for going with:

* {{single}}
* {{multi}}

This approach also fits better with the current {{VertexPropertyFeatures}} which only define {{supportsMultiProperties}} - as I look at it now, if we kept {{Cardinality}} as-is, we'd probably want to extend the feature set to inform on {{set}} and {{list}} independently.    

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