Conditional validation? about pykwalify HOT 7 CLOSED

Hmm. Conditional validation based on some completely different part of the data tree is nothing that is really supported by either kwalify or pykwalify and i am not really sure how this kind of syntax would even look to support this kind of operation. You would need some kind of logic with if/else/elseif and some way to refer to data inside the data structure and i think it would just be messy to merge together this with the regular kwalify standard.

The only solution that i can think of right now is to use the following feature https://github.com/Grokzen/pykwalify/blob/unstable/docs/Extensions.md and do some magic inside a few functions where you call one function on the classification and one on the properties and then do the validation inside those functions. It is kinda messy, but it might be a way to solve this.

from pykwalify.

Excellent points. Thank you! I tried the extensions, and the capability is quite wonderful. Still, it seemed like overdoing it for this particular use case (like you wrote, messy).

Then I thought: What I really have here are multiple schemas, one for each pass (fruit, vegetable, etc.). Why not just run them one at a time, and-ing the results together?

I don't know if there's any performance benefit by having pykwalify allow multiple schemas—that is, multiple YAML docs—even within a single file (which YAML allows for!). Apart from that, I'm going to create individual schemas and run pykwalify over each of them. Thoughts?

from pykwalify.

Ahh, turns out the individual schemas won't work in this case because of the repeated use of regex;(.+): (each template fails for all the food IDs that don't fit its particular type of food). If I could say "only have to match at least one of these" then I'd be set. Not sure if that's congruent with kwalify.

The thought of putting too many smarts into the extension also takes away from the awesomeness of using (py)kwalify.

from pykwalify.

Hi @jdandrea. I am going to close down this issue becuase i do not think that anything will come out from it as it stands currently. I have no plans of adding in some kind of if/elif/else code into the schema directly becuase that will just make the language diverge far away from the original kwalify.

My second argument is that really can do all of this conditional validation inside a custom extension/function. Yes it will be very annoying to make a full function for this small case but atleast in there you have all the freedom you want to do whatever you want. You have access to all rule objects (the schema) so you can do what ever you want inside there.

A comment on the "multiple validations on the same key/regex" problem there will not be any solution to that right now at least. I might take a stab at it in the future but right now this feature is not in the scope of being implemented.

from pykwalify.

Multiple validation paths for mapping is already tracked in issue #45 and it takes presidence over this issues

from pykwalify.

Hi! I think the case for a custom extension/function makes good sense and prevents things from diverging too far afield. Thanks for the update!

from pykwalify.

@jdandrea If you dig into extensions more, please just open up a issue if you find anything not working or if there is a need for any other data to be provided into the functions that would help towards solving this problem.

from pykwalify.