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<https://clip.dia.fi.upm.es/%7Eclip/Projects/ASAP/Software/Ciao/CiaoDE/ciao_html/ciao_153.html>,
 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 ?

On Friday, June 22, 2012 9:09:22 PM UTC+2, Sean Corfield wrote:
>
> On Fri, Jun 22, 2012 at 1:50 AM, Vinzent <ru.vinz...@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. 
> -- 
> 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

Reply via email to