ash_double_entry and updating transfers
I see a unit test that is capable of updating a transfer.
However I cannot get it to work and see this error.
I am using Postgres (16.1) and saw this in the docs:
I've played with both of these settings but still come up against the error I posted above. The mention of these two settings is confusing. Postgres is capable of "automatic cascade deletion", no?
What am I missing?
Note: There's no
ash_double_entry
tag.17 Replies
Hm....something does seem strange there. Is that case clause error happening somewhere internally? In what way are you updating the transfer?
Might need to see a repro
Latest version of everything?
You're right, it looks like possibly something that was supposed to be setting this context was removed
and so is preventing essentially the cascading balance updates required
actually, nvm
the amounts shouldn't be changing on future transfers, that stays the same
okay, I have a thought
can you try
main
of ash_double_entry
?
Its just returning the wrong format
{:error, ...}
should be {:not_atomic, ...}
The action can be done, just not atomically (because it requires multiple queries)do I need to set either of these?
Just the
references
now seeing the
:not_atomic
coming back
I added back in the inspectsupdate_transfer
is defined by you right?correct:
and
You need to add
require_atomic? false
to the update action, if you are going to allow updating the amount of a transfer.why doesn't the unit test have that defined?
https://github.com/ash-project/ash_double_entry/blob/main/test/support/transfer.ex
Ah, because its doesn't have backwards compatibility configuration set that changes how default update actions work
When I set this:
then it fails in the same way
before that config was introduced, default actions had an implicit
require_atomic? false
Its fine to add require_atomic? false
, because the relevant accounts are locked before updating them.you're a step ahead of me, I was trying to think through what gets broken if I set atomic to false. thank you for the help here!
With that said, I'm actually wondering if some recent improvements to this code that we've made lets us loosen the restriction here.
oh, no it doesn't
I remember why
the change logic uses the previous balance to do its work
So there actually is something you should do to make this safe for concurrency
that will ensure that your hook always sees the previous balance properly
if you have a chance to add a blurb about this to the docs that would be great. I'm updating the tests to use this new pattern and the new configs so its more realistic.
looks happy!
🥳