Kicking off an Oban job in the same transaction as an action
What's the right way to kick off an oban job in the same transaction as for example creating an ash?
20 Replies
Is it something like using an
after_action like this:
https://github.com/ash-project/ash_hq/blob/b94b4dfeb5b1a5f5f995efe36bff7aa4bb493fb2/lib/ash_hq/discord/resources/thread.ex#L42GitHub
ash_hq/thread.ex at b94b4dfeb5b1a5f5f995efe36bff7aa4bb493fb2 · ash-...
The Ash Framework homepage and documentation site. - ash_hq/thread.ex at b94b4dfeb5b1a5f5f995efe36bff7aa4bb493fb2 · ash-project/ash_hq
Yep! So unless you say otherwise (
transaction? false in action definition), all create/update/destroy actions will open a transaction by default. As long as you are using the same repo between oban and your resources, then it should "just work" in an after action or before action hook.
before/after action hooks will run in the same transaction as the parentis that the right idiom to use for something like kicking off oban tasks?
as in - before/after action hooks
yes, absolutely.
awesome
the other thing I'm a little confused about is whether before action hooks run before validations
it seems like they run after
allow_nil gets checked on attributes - is that right?correct. before_action hooks happen "just before" the action is actually committed, after validation and things like that.
is there another hook that runs before the validations
https://ash-hq.org/docs/guides/ash/latest/topics/actions#create-update-destroy-actions
The lifecycle is laid out in that guide.
When you say validations, do you mean
validate in the resource/action? Or do you mean allow_nil? being validated?
I assume you're setting some required attribute in a before_action hook or something like that?yup it's a slightly different use case but essentially I'm doing a file upload (from a binary) and then grabbing the url (which is required in the db) after that
I think after reading the lifecycle I just need a regular old
change , not a before_actionIf you are doing a file upload, I'd suggest doing it in a
before_action hook
or a before_transaction hook
The way to think about it is that an action's changes might be run many times potentially (like if used with AshPhoenix.Form)ah I see
the issue i'm having with the
before_action hook is that the file_url shouldn't be nilTo do what you want, though, there are a few different options
ah!
allow_nil_input says "this thing that is normally required is not required"
However, you can also just define the inputs that are "accepted" by the action. In 3.0 this will be a requirement actually. However, until then, the default behavior remains which is that all actions accept all public, writable attributes.
If an input isn't accepted by an action, we assume that you will set it at some point in your action (but validate just prior to submission still)got it
that seems better than
allow_nil_input which could potentially allow nil input through if I mess up my before_action in some wayI agree that it is better because it makes the action more clearly defined, but
allow_nil_input only allows nil input, not nil values in the actual action submission.oh ok that makes sense haha
thanks!
👍
My pleasure
ash seems super powerful but it's taking me a while to grok
it reminds me "fat models" in rails which i was a fan of.. write everything only once
Yep! I have lots of problems with ruby/rails from an execution standpoint, but ultimately the goal is to have singular definitions that lots of behavior can be derived from.
And the bigger/more variated your system is, the more that pays off.
I've kicked off the "Ash Primer" youtube series, so maybe I'll do next weeks video on the action lifecycle 🙂