If you have any feedback on the new API in the 0.3.0-alpha4 release, let me know. The whole point of the API rewrite in 0.3.0 was to move away from the *db* global dynamic variable, and deprecate all the old stuff.
Getting a final release of 0.3.0 is taking longer than I had hoped - apologies - but it's a lot of API churn and I want to make sure we've covered all our bases before 0.3.0 goes out so I don't have to make breaking changes again in the near future. The main change holding up 0.3.0 is deciding exactly what to do with transactions. I want to move away from the boolean :transaction? argument to a function-based :transaction-fn argument instead so more general transaction logic can be used. I also want to support a little more in the DDL area before 0.3.0 goes out. Thanx, Sean On Sat, Sep 7, 2013 at 12:07 AM, Alexandr Kurilin <a...@kurilin.net> wrote: > I've been using clojure.java.jdbc for a while and have been able to get away > with the query and execute! functions for most of the work, frequently > wrapping them with transactions. All three, from what I recall, give you the > option of either using an open connection (very useful for transactions) or > to just pass in a map with DB configs that will be used to open a new > connection right there and then. I remember switching away from korma and > its defdb partially for that reason. > > > On Friday, September 6, 2013 7:43:42 AM UTC-7, Jason Gilman wrote: >> >> That's excellent. I'll feel more comfortable using it in that case. >> >> >> On Fri, Sep 6, 2013 at 8:31 AM, Justin Kramer <jkkr...@gmail.com> wrote: >>> >>> clojure.java.jdbc is transitioning to an API that uses explicit passing >>> of db context - see e.g. the db-find-connection and query functions. The >>> functions that look for a dynamically-scoped db are deprecated - e.g., >>> find-connection, with-query-results. >>> >>> Justin >>> >>> >>> On Friday, September 6, 2013 8:20:11 AM UTC-4, Jason Gilman wrote: >>>> >>>> It looks like java.jdbc would work since it offers the get-connection >>>> function that returns a new connection that can be passed to most of the >>>> functions that operate on the database. I'm still concerned by the >>>> preponderance of functions with documentation like "Executes SQL commands >>>> on >>>> the open database connection." or "Returns the current database connection >>>> (or throws if there is none)". It smells like there are vars being held >>>> onto >>>> by the library that hold database connections or other state. It could >>>> still >>>> work out if I'm careful about which functions I call. >>>> >>>> What I'd really like is a library that returns some kind of context >>>> object when it connects and all functions that operate on the database take >>>> that context as an arguments. This is way more flexible, easier to test and >>>> fits more in line with the style I was going for. I'm still curious if >>>> there >>>> are other people out there who want use that same style and have to work >>>> with a relational database. I'd like to know if they just accept that's the >>>> way the libraries are written or if they have ways to get around it. >>>> >>>> >>>> >>>> >>>> On Fri, Sep 6, 2013 at 7:17 AM, Shantanu Kumar <kumar.s...@gmail.com> >>>> wrote: >>>>> >>>>> Hi Jason, >>>>> >>>>> Did you look at (URLs below) clojure/java.jdbc and HoneySQL? I'd be >>>>> interested to know if you are looking for anything different from these: >>>>> >>>>> http://clojure-doc.org/articles/ecosystem/java_jdbc/home.html >>>>> >>>>> https://github.com/clojure/java.jdbc/ >>>>> >>>>> https://github.com/jkk/honeysql >>>>> >>>>> Shantanu >>>>> >>>>> >>>>> On Friday, 6 September 2013 16:28:09 UTC+5:30, Jason Gilman wrote: >>>>>> >>>>>> I've been trying to setup all my projects in the style Stuart Sierra >>>>>> documented in Clojure in the Large and My Clojure Workflow, Reloaded. >>>>>> I've >>>>>> been trying to only use libraries that don't store any explicit mutable >>>>>> state in vars. I've been having trouble finding a Clojure JDBC library >>>>>> that >>>>>> does this. It seems like they all put the connection in some kind of var >>>>>> or >>>>>> other area. I know I could just use the Java JDBC APIs directly but I was >>>>>> hoping to avoid concatenating a bunch of SQL in my Clojure and dealing >>>>>> with >>>>>> these lower level APIs. Does anyone have any recommendations for Clojure >>>>>> libraries that might allow this? I'm also wondering if there might be a >>>>>> Java >>>>>> library with a higher level API that might allow this style. I'm betting >>>>>> other people have run into this issue with relational databases and if >>>>>> they >>>>>> have any tips for how to avoid it. (and yes I'm aware of Datomic :) ) >>>>> >>>>> -- >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Clojure" group. >>>>> To post to this group, send email to clo...@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+u...@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 a topic in the >>>>> Google Groups "Clojure" group. >>>>> To unsubscribe from this topic, visit >>>>> https://groups.google.com/d/topic/clojure/CpP0pr7bC-Y/unsubscribe. >>>>> To unsubscribe from this group and all its topics, send an email to >>>>> clojure+u...@googlegroups.com. >>>>> >>>>> For more options, visit https://groups.google.com/groups/opt_out. >>>> >>>> >>> -- >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To post to this group, send email to clo...@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+u...@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 a topic in the >>> Google Groups "Clojure" group. >>> To unsubscribe from this topic, visit >>> https://groups.google.com/d/topic/clojure/CpP0pr7bC-Y/unsubscribe. >>> To unsubscribe from this group and all its topics, send an email to >>> clojure+u...@googlegroups.com. >>> For more options, visit https://groups.google.com/groups/opt_out. >> >> > -- > -- > 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/groups/opt_out. -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ "Perfection is the enemy of the good." -- Gustave Flaubert, French realist novelist (1821-1880) -- -- 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/groups/opt_out.
