dry-transaction side effects

I’m hoping to clarify one of the stated intentions for dry-transaction. In the list of “ideas” supporting dry-transaction is the idea:

Each operation shouldn’t accumulate state, instead it should receive an input and return an output without causing any side-effects.

My question has to do with the last clause “without causing any side-effects”. Is it the intention of dry-transaction that each operation or step be free of side effects? The examples provided for using dry-transaction on the dry-rb.org site have operations that write to a database, send notifications, etc., (i.e. they have side effects). I’m guessing that the examples illustrate the intention and the statement of “ideas” is speaking of something else.

Why do I ask? While investigating solutions for a current use case I read the dry-transaction introduction and rejected it at first when I read it was intended for side-effect free usage. When I read through the examples I discovered it will work well for the use case at hand.

I would be happy to open a PR taking a stab at clarifying the intention of the idea statement if that would be helpful.

Thanks to the dry-rb team for all the fantastic work!

This is a great pickup, thank you @lancejjohnson! You’re right in pointing out that a common use case for such objects is to make “side effects” in external systems like databases and the like.

I’d definitely be happy for you to clarify this in the docs. Perhaps just removing the “without causing any side-effects” part of that sentence would be enough :slight_smile: