Re: "Clojure in the Large" style JDBC library

2013-09-07 Thread 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

On Sat, Sep 7, 2013 at 12:07 AM, Alexandr Kurilin  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  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 
 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

Re: "Clojure in the Large" style JDBC library

2013-09-07 Thread 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.

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

Re: "Clojure in the Large" style JDBC library

2013-09-06 Thread Jason Gilman 
That's excellent. I'll feel more comfortable using it in that case.


On Fri, Sep 6, 2013 at 8:31 AM, Justin Kramer  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 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 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 a topic in the
> Google Groups "Clojure" group.
> To unsubscribe fro

Re: "Clojure in the Large" style JDBC library

2013-09-06 Thread 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

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

Re: "Clojure in the Large" style JDBC library

2013-09-06 Thread 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.




On Fri, Sep 6, 2013 at 7:17 AM, Shantanu Kumar 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 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 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+unsubscr...@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.

Re: "Clojure in the Large" style JDBC library

2013-09-06 Thread 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

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