2 ms·

I found the article very hard to follow. Then I read the domain name and it all made sense... Guess our pattern is different, not really felt the pain point th

I found the article very hard to follow. Then I read the domain name and it all made sense... Guess our pattern is different, not really felt the pain point the author is talking about. Or it's the language/framework, not sure whatever the example code is written in, but setting properties on entity records would never update the database in the ones I've used. When we did things more manually we'd make sure that methods like `create_main_records` would start a transaction if not in one, and only commit if it started the transaction. This way we could nest without worry. Our database supported nested transactions but using this pattern we didn't feel the need.

nine_k 3mo ago
Tired: pass live DB model objects around, mutate them to accumulate random changes, call commit() five levels deep, experience the chaos as described by the author. Wired: fetch DB records and construct domain objects, pass them around, do mutation on the outermost level within an explicit transaction. (Typical best practice.) Inspired: "functional core, imperative shell".
andreareina 3mo ago
This is the Active Record pattern, I used to hear about it all the time. Don't know if the zeitgeist has changed or if I'm just around different parts of the internet these days.