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) >
