Given a very very simple twist on the canonical Ash Example, I just have a Ticket resource with only an id and name attributes backed by a postgres DB.
In the iex -S mix console, while playing around some more, and exploring a bit…
I execute the following code to create tickets; I see a series of INSERTs where each insert is in its own database transaction.
for i <- 0..5 do
Helpdesk.Support.Ticket
|> Ash.Changeset.for_create(:create, %{name: "Issue #{i}"})
|> Helpdesk.Support.create!()
end
So, in a very loose analogy to DDD, the Ash Resource is akin to an Aggregate Root, where the Ash action also has the job to enforce the bounded context’s business rules of the Aggregate (or Resource).
And not to get sucked into the DDD arguments of whether or not the transactional boundaries must match consistency boundaries (the aggregate root), say I still want a set of action/changes to all succeed or not…
How is that achieved in Ash? How can I get a series of resources acted upon within the same DB transaction?
Like if I wanted something similar to a “DDD Service” that takes two resources and updates them conforming to a business rule, then persisting then in a “Unit of Work” ? – Loose analogies still.
For example, say I have two chess players (each a Resource/Aggregate instance) and I want to update their ranking after a game… I want to increase the winner’s points and decrease the loser’s points, while staying consistent?
so you have a few options. Transactionality is built into Ash action. So using your chess game example, you might have something like this:
# on ChessGame
update :finish_game do
change set_attribute(:complete)
change fn changeset, _ ->
Ash.Changeset.after_action(changeset, fn changeset, game ->
# fetch players and modify their score
# whatever happens here is transactional
end)
end
end
By default things that happen in hooks will be in the same transaction. You can also start your own transactions using Ash.DataLayer.transaction(resource, fn -> end)
If your resources are in the same data layer then this works exactly as you’d expect transactions to work. If you have resources across multiple data layers, a transaction for both will be opened. This makes it technically possible to achieve inconsistency if one transactions loses and the other one doesn’t due to a network error (for example). However, it makes a good effort at cross-data-layer consistency. There are usually some things to keep in mind if you are using cross data layer actions but I won’t go into that here because I don’t think that is the main thing in question
Repeating so I understand… two options that you have suggested:
Using a “wrapping” resource, which would drive subsequent actions.
In this Chess example, it does make more sense that “ending the game” is the fundamental business change that is taking place… the player points is just a side effect action.
Use Ash.DataLayer.transaction(resource, fn -> end) , which would be outside of an Ash Resource action.
With the caveat/warning that it’s not actually 2-phase-commit across two different Repositories, rather just attempted transactions per repository.
But with the practice of only applying multi-action Ash Context API’s “bounded context”-- also assuming that each Ash Context API is strictly tied to a single Repository, we are safe…
There are usually some things to keep in mind if you are using cross data layer actions but I won’t go into that here because I don’t think that is the main thing in question
With that, I’m hearing that eventual consistency techniques would be required if we were to cross such data layer boundaries. And yes, I’m not wanting to go down a complicated rabbit hole of a multi-bounded-context distributed system (ala multiple project deployments)… Just looking at the scope of keeping things, hopefully,
straight forward simple: single domain, single bounded context, and single data layer.
You can use generic actions to use Ash.DataLayer.transaction to do arbitrary stuff in any resource.
action :name, :return_type do
argument :foo, :string, ...
run fn input, _ ->
# input.arguments.foo
Ash.DataLayer.transaction([set, of, resources], fn ->
..... do your work
end)
end
end
…or you can use the handy transaction? true option for generic actions
action :name, :return_type do
transaction? true
argument :foo, :string, ...
run fn input, _ ->
# input.arguments.foo
end
end
so you have a few options. Transactionality is built into Ash action. So using your chess game example, you might have something like this:
