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

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

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

Asaf Shakarchi commented on TINKERPOP3-773:
-------------------------------------------

[~spmallette] Thanks, will take a look, please pay attention to 2nd point as docs are showing wrong syntax.

> 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) Since I can't find any hook to intercept -before- committing, this approach enforces adding vertices / edges with all params at once (i.e can't add empty vertex, then add some props in next traversal steps)  as events are triggered immediately after each mutation and validation will fail on empty/partial vertex immediately.
> 3) For the time being, I'll restrict invocation of any mutating action out of the traversal scope, 
> What is the replacement of v1.addEdge("knows", v2) via traversal ?
> I came up with (too long IMO just to add an edge)
> Edge e = g.withSideEffect("a", g.V(v1.id())).V(v2.id()).addInE("knows", "a").next();
> and btw, the documentation shows a nice way but is wrong, under #addedge-step:
> g.V(1).addOutE('co-worker',g.V(2),'year',2009)
> but 2nd param doesn't support vertex any longer, why? so or fix docs or better get the implementation back :)
> I would really appreciate your comments about whether this is a good approach for validation constraints, 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)