arcanemachine
How to add a global error to an Ecto changeset? (Not specific to a single field)
In Django, there is the concept of “non_field_errors”, which exists when a form field has an error that is not specific to any model field.
I am just wondering if there is a similar convention in Ecto. I have an error that is not specific to a single field. How should I describe it? Should I just use the django naming convention for the field, e.g. :non_field_errors? For example:
Ecto.Changeset.add_error(changeset, :non_field_errors, "some reason")
Just checking for recommendations. Thanks
Marked As Solved
sodapopcan
Also Liked
arcanemachine
Interesting, that’s also what ChatGPT suggested. Is there any precedent for this specific value?
EDIT: The venerable Dogbert suggested the value :base in a Stack Overflow answer
sodapopcan
arcanemachine
Cool, works for me. I just want to have some sort of convention to work with. The fewer decisions I have to make, the better.
Thanks Brother sodapopcan!
Last Post!
arcanemachine
Cool, works for me. I just want to have some sort of convention to work with. The fewer decisions I have to make, the better.
Thanks Brother sodapopcan!
Popular in Questions
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #elixirconf-us
- #advent-of-code
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #hex









