# Is dry-operation replacing dry-transaction?

**URL:** <https://discourse.dry-rb.org/t/is-dry-operation-replacing-dry-transaction/1742>\
**Category:** Uncategorized\
**Created:** [October 23, 2023, 7:30pm UTC](https://discourse.dry-rb.org/t/is-dry-operation-replacing-dry-transaction/1742 "2023-10-23T19:30:56Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![timriley](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.dry-rb.org/timriley/32/25_2.png) [@timriley](https://discourse.dry-rb.org/u/timriley)\
**Post date:** [October 24, 2023, 10:50am UTC](https://discourse.dry-rb.org/t/is-dry-operation-replacing-dry-transaction/1742/2 "2023-10-24T10:50:28Z")

</div>

Hi @jpf, this is an astute observation! And yes, you’re right: dry-operation is intended to become the _successor_ to dry-transaction.

While it won’t provide an _exactly_ compatible API (this is because dry-transaction’s API turned out to have a range of limitations that are very hard to work around), it will implement all of dry-transaction’s core concepts, and our aim is to provide a straightforward upgrade path.

dry-transaction won’t go way overnight, though. If it’s useful to you, you can feel free to continue using it, but dry-operation is our focus for the future.

The benefit of providing a successor via an alternative gem is that if you choose to migrate, you can do so progressively: one class at a time, as opposed to having to do a single big-bang migration that would be necessary if we provided a new version of dry-transaction that included a bunch of major breaking API changes.

I’m really excited about what we’ll be providing with dry-operation. It’s early days for the project, so it’ll still be a few months before we’re ready to share everything, but when we do, I expect that people will _want_ to migrate because of the advantages that dry-operation provides.

---

_[View the full topic](https://discourse.dry-rb.org/t/is-dry-operation-replacing-dry-transaction/1742)._
