If you need to look at the vertices as part of your validation, i guess that gets us out of static analysis. I hadn't thought that aspect of it through completely. I would say that you are on the right track though. you would want to inject your own step beforehand and give it the arguments of the AddEdgeStep that are pertinent to your validation (if necessary). I think that would work.
On Wed, Jun 3, 2015 at 1:14 PM, Ran Magen <[email protected]> wrote: > Great thanks Stephen. How would implementing my own {{ValidationStrategy}} > work? I think I can figure out how to examine the static parameters in the > mutation steps, but how do I examine the different vertices arriving at > AddEdgeStep? Do I need to add a validating step before every mutating step? > > On Wed, 3 Jun 2015 at 20:04 stephen mallette (JIRA) <[email protected]> > wrote: > > > > > [ > > > https://issues.apache.org/jira/browse/TINKERPOP3-701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel > > ] > > > > stephen mallette closed TINKERPOP3-701. > > --------------------------------------- > > Resolution: Fixed > > Assignee: stephen mallette > > > > I've pushed what I have on this but have stopped short of "before" events > > and {{MutationCancellationException}}. I've been torn on stuffing this > > capability into the {{EventStrategy}} because it was never really > designed > > to do such things. It was build on the same premise as {{EventGraph}} in > > TP2 and was meant to provide a way to capture graph mutations. To me, > the > > notion of "validation" seems like a different thing and shouldn't be > shoved > > into this concept. I think I'd prefer to see a {{Validating}} interface > > akin to the {{Mutating}} interface with an accompanying > > {{ValidationStrategy}} but I'm not sure what that looks like at the > moment. > > > > Iit feels like you could implement your own {{ValidationStrategy}} by > just > > finding all the {{Mutating}} steps then examining the > keys/values/arguments > > supplied to them. If you don't like what you see then throw an exception > > (like the various "verification" strategies do). I think that will > largely > > satisfy that use case. > > > > In the future, I think we could kick around a more generalized feature - > > say a {{SchemaStrategy}} or the like where you could supply constraints > > that would have to be met for the {{Traversal}} to execute. As for now, > > I'm going to close this issue as it is about "improvements to the > > {{Mutating}} interface and I think that the [~mhfrantz] suggestions > helped > > cover that. [~ranma] if you think there is more to this issue > specifically > > related to "validation" please feel free to fire up a new issue with that > > in mind. > > > > > Improving Mutating Interface > > > ---------------------------- > > > > > > Key: TINKERPOP3-701 > > > URL: > > https://issues.apache.org/jira/browse/TINKERPOP3-701 > > > Project: TinkerPop 3 > > > Issue Type: Improvement > > > Components: process > > > Reporter: Ran Magen > > > Assignee: stephen mallette > > > Priority: Critical > > > Fix For: 3.0.0.GA > > > > > > > > > This was discussed in the mailing list. Ill quote the relevant parts: > > > We want to implement a validation strategy. Sort of like EventStrategy, > > but it will notify before a mutation, and will enable the user's > validation > > code to cancel a mutation if it doesn't pass its checks. The problem is > > that there are no "before" callbacks for the Mutating interface. > > > Stephen Mallette: > > > i may have messed up the Mutating interface design a bit. looking at > it > > now, i feel like it could be less coupled to the EventStrategy related > > features. I'll take a look at it to see if I can make it "better" before > > GA. I don't think my changes should affect vendors or the test suites, > so > > if it turns out to be that way i'll give it a shot. > > > > > > > > -- > > This message was sent by Atlassian JIRA > > (v6.3.4#6332) > > >
