What I'm talking about is whether it's a better pattern to leave a repetitive and error prone task to the user or encapsulate it in a single place. The whole discussion boils down to following options.
The first option is that we keep functions pure and the connection is passed as a parameter by the person writing the code (the user). With this approach the burden is squarely on the user to remember to pass the correct connection to the function. This becomes error prone for things like transactions where the developer has to pass the transaction connection as opposed to the normal database connection. The worst part in this scenario is that the code will run except it won't run transactionally. This is a bug that is difficult to catch as it only surfaces in cases where the transaction should be rolled back. The alternative is to encapsulate the database connection management in the initialization logic in the namespace managing the connection. This way the query functions can be context aware and ensure that the correct connection is used automatically. I simply disagree that leaving repetitive and error prone tasks to the developer as opposed to encapsulating them centrally is a better pattern. I certainly don't see that as a feature. On Wednesday, August 5, 2015 at 8:19:38 AM UTC-4, James Gatannah wrote: > > > > On Monday, August 3, 2015 at 10:21:09 PM UTC-5, Dmitri wrote: >> >> My understanding is that the problem is actually caused by the stateless >> nature of the functions. >> > > You're talking about database interactions. By definition, those are not > stateless. The trick is to isolate this statefulness as much as possible. > Expanding it just compounds the problem. > > > >> Since the function accepts the connection as a parameter it's up to the >> user of the function to ensure that it's passed the correct connection. >> > > That depends on what you mean by "user of the function." If I'm working on > the web server front-end, I shouldn't have any idea about the database > connection. I should describe what I > want to happen. If I have any concept that multiple databases are involved > (I shouldn't, but abstractions leak), then, yes, I have to specify which > one I mean. This isn't > complicated. > > It's up to the person writing the database back-end code (also possibly > me, if we're talking about a start-up, but then we aren't talking about the > 200 KLOC scenario) to turn that > description into the side-effects. > > > >> Every functional solution presented in this thread suffers from this same >> fundamental problem that the function is not aware of the context it's >> being run in. >> > > That isn't a problem: it's a feature. > > It doesn't matter what language or programming paradigm you're using in > this context. This cuts across problem domains and architectures. > > The actual database interaction code should be as brain-dead simple (not > "easy") and bullet-proof as you can possibly make it. And it should be as > isolated from the front-end code as you can get away with making it. > > That isn't a "right" answer. But it's a good rule of thumb. And you should > have very hefty reservations (and very good reasons) about violating it. > > Respectfully, > James > > -- 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.
