Cool article Rémi. I'm confused about why you would use dry-transactions when Rails already uses transactions in model callbacks.
For instance, you could do after_save :send_emails, and then put all of your logic within a private method you would end up with a similar situation. All of the logic would be wrapped and protected in the protective transaction cover.
I think the naming that the dry-transactions gem uses is definitely throwing people here (and I think missing the point Rémi is trying to make). This is less about wrapping code chunks in database transactions, and more about extracting business logic into processable steps to better align with how operators of the business perceive the flow of their clients (users).
I've used a couple other gems (namely trailblazer, and waterfall) which provide an entire framework for taking this idea a step further. Having worked with Trailblazer the most recent, I can say that simply having a rigid structure for processing data through chainable events (as is done in this great article) was an incredible dev experience that clearly defined a picture of what was happening and why.
Rails controllers are great for gathering data and directing it to the right pipeline, but I can't say I've come across anything remarkable in Rails that helps establish these pipelines.
Ruby on Rails developer - Maker of ✨ things on the Internet. O(🐌^n) kind of guy. Alumni @lewagonparis (batch 145). Builds wooden furniture on his balcony.
Ruby on Rails developer - Maker of ✨ things on the Internet. O(🐌^n) kind of guy. Alumni @lewagonparis (batch 145). Builds wooden furniture on his balcony.
I am a Senior Software Engineer currently working on Ruby, Rails, ReactJS. My previous experience includes, PHP along with CakePHP, CodeIgniter and Kohana.
Ruby on Rails developer - Maker of ✨ things on the Internet. O(🐌^n) kind of guy. Alumni @lewagonparis (batch 145). Builds wooden furniture on his balcony.
I thought that Lead.transaction - to use your example - only allowed me to wrap database operations as a single unit. With the dry-transaction it's more about any kind of operations. But maybe I am missing something.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Cool article Rémi. I'm confused about why you would use
dry-transactions
when Rails already uses transactions in model callbacks.For instance, you could do
after_save :send_emails
, and then put all of your logic within a private method you would end up with a similar situation. All of the logic would be wrapped and protected in the protective transaction cover.I think the naming that the
dry-transactions
gem uses is definitely throwing people here (and I think missing the point Rémi is trying to make). This is less about wrapping code chunks in database transactions, and more about extracting business logic into processable steps to better align with how operators of the business perceive the flow of their clients (users).I've used a couple other gems (namely trailblazer, and waterfall) which provide an entire framework for taking this idea a step further. Having worked with Trailblazer the most recent, I can say that simply having a rigid structure for processing data through chainable events (as is done in this great article) was an incredible dev experience that clearly defined a picture of what was happening and why.
Rails controllers are great for gathering data and directing it to the right pipeline, but I can't say I've come across anything remarkable in Rails that helps establish these pipelines.
I wouldn't have been able to explain this better. Thanks @codenamev for this great explanation and the kind words!
Hey Kobe, thanks for your question. To be honest, I wouldn't know how to answer this one.
Could I add several
after_save
and handle the return of each action?I was going to post the same thing. This can be handled by rails without the need of an additional gem.
Maybe I am missing something.
I thought that
Lead.transaction
- to use your example - only allowed me to wrap database operations as a single unit. With thedry-transaction
it's more about any kind of operations. But maybe I am missing something.