[
https://issues.apache.org/jira/browse/TINKERPOP3-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14632357#comment-14632357
]
stephen mallette commented on TINKERPOP3-773:
---------------------------------------------
I don't see that syntax anywhere - are you sure you are looking at the latest
docs?
http://tinkerpop.incubator.apache.org/docs/3.0.0-incubating/#addedge-step
> 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)
