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

["Asaf Shakarchi (JIRA)" <ji...@apache.org>]

Asaf Shakarchi created TINKERPOP3-773:
-----------------------------------------

             Summary: Best approach to enforce mutation validations
                 Key: TINKERPOP3-773
                 URL: https://issues.apache.org/jira/browse/TINKERPOP3-773
             Project: TinkerPop 3
          Issue Type: Task
          Components: process
    Affects Versions: 3.1.0-incubating
            Reporter: Asaf Shakarchi
            Assignee: Marko A. Rodriguez


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)