Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Schema validation errors on polymorphic embeddings are too vague and do not align with Ecto's embeds_* #112

Open
bvobart opened this issue Aug 27, 2024 · 0 comments

Comments

@bvobart
Copy link

bvobart commented Aug 27, 2024

Hi @mathieuprog, how are you? :)

As mentioned in my Elixir forum thread here, I notice that the schema validation errors on polymorphic embeddings are very non-descriptive.

E.g. if I have a schema with a polymorphic embed on :children and data where one of those children has an invalid type field, then casting it with changeset results in an Ecto.Changeset struct with changeset.errors == [children: {"is invalid", []}]. Note that this does not contain any info about the particular element within :children that caused the error, or what the underlying error actually was.

I’ve created a minimal working example in a GitHub repo here just to illustrate the point a bit better: https://github.com/bvobart/polymorphic-embed-errors-mwe

See lib/schema.ex and test/schema_test.exs to see what I mean. I’ve added some tests that show the current behaviour and the behaviour that would be desirable (and that would be more akin to what Ecto does for embeds_many).

I found that this line is where the indescriptive error is added. I feel like it should be possible to add a more descriptive error in the Enum.map before it, i.e. here. Although I'm not sure what would be necessary to make it behave more like Ecto's embed_one and embed_many as shown in my example project's test case. It might be dependent on #74 but I'm not sure.

What would be the best solution for this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant