"Clojure in the Large" style JDBC library

[Jason Gilman]

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 :) )

[Shantanu Kumar]

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

[Jason Gilman]

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.

--
--
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.

[Justin Kramer]

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

[Jason Gilman]

That's excellent. I'll feel more comfortable using it in that case.

[Alexandr Kurilin]

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.

[Sean Corfield]

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

> 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+u...@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)