[
https://issues.apache.org/jira/browse/TINKERPOP3-612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14491615#comment-14491615
]
pieter martin commented on TINKERPOP3-612:
------------------------------------------
Another thought,
I reckon its better for tinkerpop to have strong semantics that a
implementation either implements or not.
Having weak semantics with potentially different implementations defeats the
purpose of being vendor agnostic.
As it is it is difficult for clients to keep their code base vendor agnostic.
The ideal of being able to swap out back ends from some embedded db to a
distributed solution is something tinkerpop is close to achieving.
> 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)
