I have heard this approach before, but I have never seen how it works in real life. For example, what about 'selects' - where do they happen? What about if my updates are not independent (e.g. if the first update works then do the second update otherwise do this completely different thing?).
For simple workflows I can see the elegance. For non-trivial workflows the problem is that _accessing_ the DB and _switching_ on the DB logic tends to be all through the workflow. I am genuinely interested in the answers to this as yes, the described approach has some great benefits. James Gatannah writes: > On Thursday, July 30, 2015 at 7:44:31 PM UTC-5, J. Pablo Fernández wrote: >> >> Hello Clojurians, >> >> I found passing around the database connection to each function that uses >> it very error prone when you are using transactions as passing the wrong >> one could mean a query runs outside the transaction when in the source code >> it is inside the with-db-transaction function. >> > > I'll go ahead and make the point that it's error-prone for different > reasons. > > Pretty much by definition, that database connection is a system boundary. > It's all about something that's *way* more complex than random global state > changes inside your program. This is a thing that interacts with the > outside world, with all the nastiness that implies. > > Everything that everyone else has already written about this approach is > true, but I don't think they've gone far enough. > > Even if you pass that database connection around as a parameter everywhere, > you're talking about throwing away a huge part of the benefit of using a > functional language. > > Isolate your side-effects. > > Think of a castle. You have a moat surrounding it, and a few gates that you > use to allow your peasants to enter/exit. This particular gate opens up to > a swamp full of alligators. > > Your approach amounts to letting the gators wander around loose. > > Passing the connection around to each function in the call chain is like > tying a ribbon around the gator's neck and hoping you can use that as a > leash. > > You can use either approach to great effect. If you're really, really good. > And so is everyone else on your team (you did mention a 200 KLOC project). > > One of the main benefits to functional programming is that admitting you > aren't really, really good is incredibly liberating. I don't have the > time/energy to dedicate to trying to maintain this sort of code. (Yes, I > spent lots of time recently thinking about how java was designed for very > average programmers, but it really takes much better programmers than a > functional language to actually write correct programs). Even if I were > that good...I'd rather be focused on the problems that make my customers > happy. > > I'm going to appeal to authority here for the right > answer: http://prog21.dadgum.com/23.html (in my defense, it's a great > blog). Have your web response handler (which is another system > boundary...this one is next to an active volcano populated by > fire-breathing dragons) build up a list of all the nasty side-effects that > will eventually have to happen. > > Don't just isolate your side-effects. Quarantine those suckers as if each > and every one means you're dealing with the most diabolical hacker you can > imagine. -- Sent with my mu4e -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
