[FEATURE] Integration with Ecto

[zoedsoupe]

Description Peri schemas should be parseable as Ecto.Changesets and vice versa. This allows the Peri library to be as extensive as possible while providing seemanless integration and retrocompatibility with ecto schemas.

Motivation ecto syntax for define deeply nested schemas and more complex validation lack the simplicity of Peri, however not interfacing with ecto schemas seems to be a block to the library usage in some use cases.

Alternatives

• maybe a function to convert peri schema definition to a changeset?
• maybe define ecto schemas on the defschema/2 macro? (should be optional, will relay on macros and code generation)
• maybe convert ecto changesets to Peri schemas?

Additional Context N/A

[joeljuca]

How do you imagine it being implemented? Some function, eg.: to_changeset() or smt like that?

[zoedsoupe]

yeah, exactly something like that. i don't want to build ecto schemas (aka structs) because peri already handle the schema definition. so the idea was to target schemaless changesets...

there are some considerations though, like peri can be used on raw data structures and types, and support various kinds of validations that ecto doesn't, so some schemas would be "truncated"

[joeljuca]

The issue I can see right away is that Peri does not have a data structure to represent a pipeline of validations (smt like %Ecto.Changeset{} that encapsulates the struct, the param map/keyword list with changes being applied to it, the validation status, and a list of errors that can be appended with more errors, etc.). IIUC, Peri's validation pipeline relies on tuple-wrapped returns with :ok/:error prefixes.

It seems that some state is being lost through the pipeline, so it might require quite a bit of rewrite – but I might not be seeing the whole thing through. How do you imagine implementing it? Could you draft a quick-and-dirty description of how it could bew implemented?