Thanks for your explanation and advice. I really appreciate it.
rapidfsub
zachdaniel
Creator of Ash
Writing atomic code is harder, but here is an example of a case where it will pay off significantly:
update :add_ten_to_score do
change fn changeset, _ ->
Ash.Changeset.change_attribute(changeset, :score, changeset.data.score + 10)
end
end
The action above raises an error about it not being atomic. In this case, the effect here is that if you ran this same update concurrently on the same record, it’s possible to have inconsistent results.
i.e with a record that has a score of 0
Action 1: record is read, current score: 0
Action 2: record is read, current score: 0
Action 1: new score is determined, new score 10
Action 2: new score is determined, new score 10
Action 1: data is written, new score 10
Action 2: data is written, new score 10
So now even though the action was called twice, and you’d expect a new score of 20, you actually have a new score of 10.
By using an action like this:
update :add_ten_to_score do
change atomic_update(:score, expr(score + 10))
# or use the built in
change increment(:score, amount: 10)
end
you now have a fully atomic update that does not have the same problems as described above
I’ve made some tweaks to the atomic update docs to potentially help with clarity. Update Actions — ash v3.29.3
3
zachdaniel
Creator of Ash
So in a way, its supposed to be slightly annoying, and if it drives folks to understand what it means for an action to be atomic and why it matters then its doing its job 
Its worth highlighting a snippet from those docs though:
Not all actions can reasonably be made atomic, and not all non-atomic actions are problematic for concurrency. The goal is only to make sure that you are aware and have considered the implications.
0
rapidfsub
I am also a race condition worrying guy.
But I think many folks would write a spark dsl for “automatically setting require_atomic? false”,
because require_atomic? true is rare case for most apps. 
0