Extensions for dry-logic and dry-validations to support Open API schemas

Ideas
1

While developing new api we discovered that dry-validation suits best for our needs as a validation library.
We’re describing our API with OpenAPI 3 and one of the things we want to develop in future is automatic dry-validation schema generation based on OpenAPI schema.
However there are few things, that dry-validation and/or dry-logic seem to lack:

  1. While Open API oneOf with discriminator could be exposed through when rule, without it there is no such capabilities, except constructions like (a.and(b.not).and(c.not)).or(b.and(a.not).and(c.not)) ... etc which doesn’t work properly every time and doesn’t generate meaningful errors.
  2. Open API anyOf could be exposed through or but the errors are not meaningful.
  3. not doesn’t work properly with schemas.

What I want to suggest is to add the corresponding rules to dry-logic and dry-validation and below is what I have at this moment:

  1. I have a code prepared for anyOf rule for dry-logic, I called the rule part and I have 2 questions:
    a) Should I return all rules ASTs in case of failure?
    b) Is name part good for anyOf rule?
  2. I have a code prepared for oneOf rule for dry-logic, I called the rule one and I have 3 questions:
    a) Should I return all rules ASTs in case of failure?
    b) Is name one good for oneOf rule?
    c) Does it make sense to extend this rule to have the second parameter - int or range - the number rules it has to satisfy, so that it would become a general rule nOf?
  3. I haven’t prepared code for neither for oneOf nor of anyOf in dry-validation and there are some things I want to discuss:
    a) I want errors for oneOf and anyOf to be like " not one of (list of rules)" and " not any of (list of rules)", but I think in case of schemas passed the shouldn’t be expanded to AST, so that the error could be " " not one of Cat, Dog, etc.", but currently they come to message compiler already expanded. What’s better to do here? This could also help with exposing rules like schema(Cat).not, which could be added via add_rule and currently returns the errors of the Schema errors when there are errors.
    b) What should be the names of the rules? I was thinking about one and any.

Probably generating from Open API will require some more extensions, so in general there is also a question, are you interested in Open API support in dry-validation?

2

Yes, it would be fantastic if we could provide various extensions to ease the process of defining schemas. At the moment though, we need to hold off until dry-schema + dry-validation 1.0.0 are ready.

3

Makes sense. Are there any roadmap or tasks for these gems? I’m ready to contribute.

4

We started working on dry-schema first, where ~90% of existing dry-validation DSL will be implemented. It’s a rewrite, except message generation part which was copied from dry-validation (we may tweak it later on though). If you’d like to help, you can look at this PR and see if you can get more specs passing.

Check out this too => Plans for dry-validation + dry-schema (a new gem!)