Hey Pablo, Sorry, you are completely correct: I accidentally typed transaction when I meant connection. My bad.
I don’t understand what you mean by connections having to be global when dealing with an RDBMS. It is true that you normally want to pool them to conserve resources, and that pooling may be global in nature - but it also may not be. Quality of Service demands often necessitate multiple pools to the same data-source to be created and accessed independently. You also, sometimes, want to access different databases from the same application, that gets much harder - and your code becomes less general if you need to reference specific global connection-pools. I’m also a little confused by your suggestion that it would be impossible to enclose each test in a transaction. The article you point to shows one way. Another way I’ve used often is to declare a var holding a ref and in a fixture initialise/close a connection around the test. The test function then derefences the var holding the connection passing it into the function under test. This does make it impossible to run tests in parallel, but that’s not something I’ve ever tried. Creating tests that access shared resources is a little bit uglier than in a OO language where you could more easily reference an instance variable but it isn’t much worse, and a little macro-pixie dust can make it all go away. I will say that it has been my experience that you don’t find yourself passing database connection pools around everywhere. As your code grows you naturally extract components/protocols that wrap all that up. Your ring-handler doesn’t need a connection it needs some sort of data-access component. That component needs a connection/connection pool but that can be passed in at construction time. I have feared the creation of functions that need an ever increasing number of parameters that need to be passed on, but it isn’t something I find happens in practice. Of course, YMMV. I would respectfully suggest that the solutions are not the same. My way has no global state and functional purity-lite (those connections are rarely idempotent): which are obviously only theoretical benefits. But it does work when I do it; I like my code, I don’t have problems working with it, and I genuinely don’t face any of the challenges you’re struggling with. R. > On 3 Aug 2015, at 03:19, J. Pablo Fernández <pup...@pupeno.com> wrote: > > Rob, > > The transactions are not global, the transactions are local. Connections are > global and there's no way around it with the constraints of a traditional > RDBMs. Your idea of making the global connection unavailable for code that's > in the context of a transaction would prevent the errors I'm trying to > prevent but you would still required to pass the connection around, which in > a webapp, means that the whole chain of function calls, pretty much > everything, would have a database connection. That is ugly in some cases, > impossible in others. > > A piece of code that would be impossible is to enclose each test in a > transaction using clojure.test: > http://stackoverflow.com/questions/31735423/how-to-pass-a-value-from-a-fixture-to-a-test-with-clojure-test > > <http://stackoverflow.com/questions/31735423/how-to-pass-a-value-from-a-fixture-to-a-test-with-clojure-test> > > Furthermore, I don't think this solution gains you any purity, you still have > a global estate and you are hiding it away when starting a transaction. My > proposal was to make it work instead of hiding it. They are rather equivalent > from the complexity point of view. -- 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.
