[ANN] clojure.java.jdbc 0.2.3 available on Maven Central

[Sean Corfield]

Just two changes in this release:

* as-str now treats a.b as two identifiers separated by . so quoting
produces [a].[b] instead of [a.b]

This was a bug that I'm kind of surprised no one had tripped over yet.
I fell over it as soon as I tried to build a DSL on top of the
library.

* Add :connection-uri option
[JDBC-34](http://dev.clojure.org/jira/browse/JDBC-34)

This was added in response to an observation by Chas Emerick about the
lack of any way to create a connection directly from a raw connection
URL and the DriverManager.

The next "big" release will add a new, more functional API (query,
execute!, insert!, update!, delete! etc). The jury is still out on a
simple DSL for common SQL operations. You can see a hint of where I'm
going in this repo: https://github.com/seancorfield/jsql

Clarification (based on some off-list comments I've received): I have
no intention of trying to shoehorn something like Korma or ClojureQL
into java.jdbc. Any DSL that gets added will be simple and only
intended to deal with common cases - and with an easy way to drop down
to SQL itself. The main thrust is to get an API i place that doesn't
rely on dynamic variables.
--
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)

[Vinzent]

Actually, jsql looks very much like clojureql\korma. Honetly, I wish see better support for clojureql rather than new similar DSLs coming up.

четверг, 21 июня 2012 г., 11:36:24 UTC+6 пользователь Sean Corfield написал:

[Sean Corfield]

On Thu, Jun 21, 2012 at 12:33 AM, Vinzent <ru.vi...@gmail.com> wrote:
> Actually, jsql looks very much like clojureql\korma.

jsql has completely different goals to ClojureQL/Korma and is mostly a
convenience for generating the sort of SQL that the update!, insert!
and delete! methods need under the hood (c.j.jdbc has to generate that
SQL anyway - might as well make the methods public). The
select/where/order-by has evolved out of our common usage at World
Singles where we have get-by-id and find-by-keys and similar CRUD
functions. jsql is deliberately very close to the "metal" of SQL and
is not intended to be composable etc. Folks wanting a full-blown DSL
should indeed use Korma (or ClojureQL).

> Honetly, I wish see
> better support for clojureql rather than new similar DSLs coming up.

Lau hasn't updated ClojureQL for a while - if you want better support,
perhaps you should approach him and contribute to that project?

[Kevin Downey]

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

given java.jdbc's position as the sort of lower level glue all these
libraries are built on, maybe better then including a DSL in java.jdbc
would be including an AST (some data representation of sql) and a
compiler for same.

you can argue that "well code is data" so the dsl is an exposed data
representation of sql, none of the dsls are low level enough to be
targeted by any of the others.

--
And what is good, Phaedrus,
And what is not good—
Need we ask anyone to tell us these things?

[Vinzent]

given java.jdbc's position as the sort of lower level glue all these
libraries are built on, maybe better then including a DSL in java.jdbc
would be including an AST (some data representation of sql) and a
compiler for same.

Yeah, that's exactly what I wanted to suggest too. Seems like all would benefit from that. Though, the same idea has already been discussed on the list some time ago.

@Sean Corfield:

jsql has completely different goals to ClojureQL/Korma and is mostly a 
convenience for generating the sort of SQL that the update!, insert! 
and delete! methods need under the hood (c.j.jdbc has to generate that 
SQL anyway - might as well make the methods public). The 
select/where/order-by has evolved out of our common usage at World 
Singles where we have get-by-id and find-by-keys and similar CRUD 
functions. jsql is deliberately very close to the "metal" of SQL and 
is not intended to be composable etc. Folks wanting a full-blown DSL 
should indeed use Korma (or ClojureQL). 

Ok, I see. I've misunderstood the goals. Though, it still duplicates significant part of clojureql\korma, right? What do you think about AST\compiler thing?

[Sean Corfield]

On Fri, Jun 22, 2012 at 1:50 AM, Vinzent <ru.vi...@gmail.com> wrote:
> Ok, I see. I've misunderstood the goals. Though, it still duplicates
> significant part of clojureql\korma, right?

Hmm, I wouldn't say a "significant" part. I think jsql covers a very
small space. To satisfy the basic goal for the new c.j.jdbc API, it
only really needs the insert/update/delete functions and folks could
use SQL for all other queries - but basic select/where is useful
enough that I think it's worth adding (to be able to use a map for a
simple query).

> What do you think about AST\compiler thing?

I'd love to see some examples of what Kevin / you have in mind here.
Feel free to edit http://dev.clojure.org/display/design/java.jdbc to
add some examples / thinking around AST.

[Niels van Klaveren]

I also can't help but think this is overlapping with ClojureQL/Korma. Korma also isn't that far from the 'metal' this library is shooting for. The biggest problem with SQL is that it isn't functionally composeable. Otherwise why use a DSL instead of SQL itself ? It seems a pretty well-designed DSL for working with relational databases :) Judging from the design of the clojure.java.jdbc query support one would need solid SQL knowledge to begin with.

On the one hand, another library of very limited scope wouldn't hurt. But on the other hand, both Korma and ClojureQL could use a bit of a boost. Korma could really use a function like SQL Alchemy's autoload to work with existing databases. That should be doable with better JDBC metadata based functions, which I think would be an appropriate match for clojure.java.jdbc. Such a library could be used in a Korma spin-off library to auto-generate Korma 'entities'. 'Insta-korma' anyone ?

ClojureQL had the nice idea to elevate itself above SQL. That makes it seem a bit more 'alien' than Korma or your initiative. The queries generated don't seem very efficient compared to the scope (advanced database use) one would use it to generate queries for. Also, development on it seems to be dwindling.
 
I was thinking if an SQL generation DSL / library could be based on core.logic ? Defining 'facts' a bit like Korma's entities (which could also be derived from JDBC metadata), a set of SQL dialect 'facts', and a set of base SQL facts and goals, with the programmer adding goals through a DSL to generate the desired SQL queries ? I found something like that has been done in Prolog , but as far as I found that's the only one.

Clojure could really use a great 'conventional' relational database stack like Python has in SQL Alchemy. A lot of the bases have been covered by Java and clojure.java.jdbc. Our web stack is built on small libraries building on eachother's strengths, could we do the same here ?

[Vinzent]

Our web stack is built on small libraries building on eachother's strengths, could we do the same here ?

Yeah, that's exactly what I had in mind. Just like Ring, c.j.jdbc could accept maps and generate corresponding sql code, thus eliminating the need to write a compiler for each sql DSL.

[mnicky]

On Saturday, June 23, 2012 1:20:30 AM UTC+2, Niels van Klaveren wrote:

 
I was thinking if an SQL generation DSL / library could be based on core.logic ? 
 

Something like revival of clojure.contrib.datalog would be great.

[Niels van Klaveren]

You can use the Datomic datalog implementation to query Clojure collections. I think this is the same use clojure.contrib.datalog had.

[mnicky]

Thanks! However it'd be nice if it was released as a separate library.

Also, I thought that clojure.contrib.datalog worked for SQL queries... That would be even better ;)

[Niels van Klaveren]

Yeah, it's a pain to include Datomic's Datalog implementation through Maven dependencies, since you need to install the jar by hand. Afaik clojure.contrib.datalog didn't compile to SQL. Theoretically it should be possible to do so, since Datalog is a superset of SQL. However, the extra functionality in Datalog would be hard to implement in SQL (for instance, recursive queries), and result in a lot of not very optimal SQL queries.

[Chas Emerick]

Random thought: recursive queries are possible in SQL using recursive common table expressions.  The PostgreSQL manual has a good introduction to them:

http://www.postgresql.org/docs/9.1/static/queries-with.html

And another introduction to them, in the particular area of querying hierarchical data using recursive CTEs:

http://explainextended.com/2009/07/17/postgresql-8-4-preserving-order-for-hierarchical-query/

Cheers,

- Chas

[Kevin Downey]

that is very interesting, I've played around with generating sql from
datalog queries, but stopped when I ran up against generating queries
for recursive datalog rules because I wasn't aware of WITH RECURSIVE

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