carlgleisner
Eager checking on multiple attributes supported?
Is it supported to have eager_check?: true run on identities when the identity consists of more than one attribute?
I have a compound identity that indeed returns errors on submission with Postgres as data layer. On another resource using an identity with a single attribute I do get eager checking on validation however, as one would expect of course.
identities do
identity :imaginative_party_name, [:host_id, :party_name] do
eager_check? true
message "success not possible if you insist on reusing party names all the time"
end
end
Looking at the documentation I cannot tell that this would not be supported. If so, then maybe this could be pointed out?
Marked As Solved
carlgleisner
It works ![]()
The thing was that I was using argument for the input of the key of the related record together with a change with manage_relationship. As I understand it now this is intended behaviour.
I dug up a few of your messages in the Discord which I think explain it:
I think you [i.e. another person] may be running into an issue around when managed relationships actually happen. Managing relationships is a bit special insofar as the logic to actually do so is handled by calling the action.
So when your validation runs, the
technician_idis never going to be set.You have a few options:
- don’t use managed relationships for the belongs_to relationship
- run your validation in an
after_actionhook in a customchange- run your validations in the action, based on the arguments instead
You put examples in there as well, very helpful. Maybe I could copy these here as well if appropriate?
Humbly, maybe a note in the documentation could be of use for others? I’d be happy to provide a PR as a starting point if desirable.
Sidenote
I’m yet to try out the solutions you suggested since for now it’s just fine for me to not use argument+change. But I did wonder whether that also solves not getting errors after submission when passing in input that does not relate to the id of an existing record.
Reference codebase
I used this little reproduction for testing for future reference.
But I guess it’s technically not a “reproduction” when there is no actual issue ![]()
https://github.com/carlgleisner/ash_phoenix_reproduction
EDIT: I should edit the title of this post for posterity
Also Liked
zachdaniel
You would have my utmost gratitude ![]()
This one would probably be a separate issue? Likely has something to do with input names not matching? But curious to see if its still an issue after your change ![]()
zachdaniel
Last Post!
zachdaniel
You would have my utmost gratitude ![]()
This one would probably be a separate issue? Likely has something to do with input names not matching? But curious to see if its still an issue after your change ![]()
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
- #api
- #forms
- #metaprogramming
- #security
- #hex









