[
https://issues.apache.org/jira/browse/TINKERPOP3-773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Asaf Shakarchi updated TINKERPOP3-773:
--------------------------------------
Description:
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.
was:
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.
> 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)
