[
https://issues.apache.org/jira/browse/TINKERPOP3-489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette closed TINKERPOP3-489.
---------------------------------------
Resolution: Duplicate
Closing in favor of duplicates: TINKERPOP3-520 and TINKERPOP3-519 - made
reference to this issue in both of those as there is a lot of good talky-talk
in this one.
> meta-properties and multi-properties for security and history
> -------------------------------------------------------------
>
> Key: TINKERPOP3-489
> URL: https://issues.apache.org/jira/browse/TINKERPOP3-489
> Project: TinkerPop 3
> Issue Type: Improvement
> Components: structure
> Affects Versions: 3.0.0-incubating
> Reporter: Bryn Cooke
>
> Recently I have been looking at history and security GraphStrategies with
> [~rjbriody] and it seems like meta-properties and multi-properties may not
> fulfil their potential in their current form. In particular due to the lack
> of support on edges.
> Meta and multi-property support is at the cost of a more complex element api
> than TP2 get/setProperty, so it's worth making sure that the extra effort is
> worth it for end users. (https://github.com/tinkerpop/tinkerpop3/issues/389)
> Here are the use cases and the difficulties faced:
> h3. SecurityGraphStrategy
> * User wants to restrict access to reading/writing a property on an element
> on the graph. This applies equally to edges as well as vertices.
> h4. Issues
> * ACL information could be stored in meta-properties. However as there is no
> support on edges I end up using prefixed properties instead.
> * Lists of users and groups could be store in multi-properties, but again the
> lack of edge support means that I end up concatenating the users and groups
> to a string which is then indexed via contains.
> There seems little point in having a different strategy for edges and
> vertices, so currently I'm not using VertexProperty at all to implement
> security.
> h3. HistoryGraphStrategy
> * User wants to be able to view the state of an element at any point in
> history. This applies to edges as well as vertices.
> h4. Issues
> * Historical property data could be stored in a list in a meta-property.
> However, edges are not supported and meta-properties can not also have meta
> properties, so if the original property had meta-properties they could not be
> stored in a meta-property.
> * Historical property data could be stored in a list in a prefixed property.
> However, edges are not supported. I will probably end up creating a history
> vertex and storing the data there. Edges will have to be linked via UUID to
> the history vertex and for consistency vertices will probably do the same.
> Even with this hack I will still have to disable meta-properties for the
> client as I can't store meta-properties on meta-properties. An example of
> when I would want to do this would be to store the history of ACL.
> h3. Observations
> * I'm having to fall back to prefixing way too often.
> * The benefit of meta-properties does not seem to be clear cut over prefixing
> especially as they are not supported on edges, but also that meta-properties
> can also not have meta-properties.
> * End users will not understand why there is a distinction between element
> types for properties, and if they have to support edges then they'll end up
> using prefixing and custom serialization anyway. No matter how many times the
> reasoning is explained people will continue to ask. Get ready to start
> pushing a boulder up a hill.
> And lastly questions:
> * If via custom serialization e.g. JSON I can store structured data in a
> property and it will work on all types of element, then is a dedicated API
> only on vertices definitely worth the extra complexity? If I am really lucky
> then my Graph implementation may even support indexing JSON.
> * Do we think that vertex only history and security will be the main
> requirement of users, or will they want full graph support?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
