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/07/18 02:03:04 UTC

[jira] [Updated] (TINKERPOP3-773) Best approach to enforce mutation validations

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

stephen mallette updated TINKERPOP3-773:
----------------------------------------
             Assignee: stephen mallette  (was: Marko A. Rodriguez)
    Affects Version/s:     (was: 3.1.0-incubating)
                       3.0.0-incubating
           Issue Type: Improvement  (was: Task)

> Best approach to enforce mutation validations
> ---------------------------------------------
>
>                 Key: TINKERPOP3-773
>                 URL: https://issues.apache.org/jira/browse/TINKERPOP3-773
>             Project: TinkerPop 3
>          Issue Type: Improvement
>          Components: process
>    Affects Versions: 3.0.0-incubating
>            Reporter: Asaf Shakarchi
>            Assignee: stephen mallette
>
> Hey,
> I am trying to find the most appropriate way to enforce some mutation validations, I know this is a bit beyond Gremlin's playground but I dislike the concept of enforcing validations on the vendor implementation to avoid vendor lock, 
> Since graph wrappers are gone (Old T2 EventGraph was decorating everything so it was easy) The only way I could think of is by leveraging the EventGraph Strategy,
> So I hook into the events and throw exception if an illegal change occur so as long as events are thrown before commit it should be fine (I use the default event queue even when TX is available so it should be sufficient)
> I have some comments/questions though:
> 1) The EventGraph events are triggered only via traversal steps, so direct G/V/E mutation are bypassed (i.e v.addEdge, direct modify/drop of v.property()), I guess it's up to the implementation if to throw events or not, or maybe we can do some AOP here... comments?
> 2) For the time being, I'll avoid invoking any mutating action out of the traversal scope, but I can't find a simple way to add an edge to a vertex without saving vertices in scopes,
> What is the replacement of v1.addEdge("knows", v2) via traversal ?
> btw the documentation is wrong under #addedge-step
> it shows a syntax such:
> g.V(1).addOutE('co-worker',g.V(2),'year',2009)
> but 2nd param of addOutE is a string,
> I would really appreciate your comments about whether this is a good approach or there's a better alternative except hooking into vendor's specific approaches directly.
> Thanks.



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