
ClojureQL - 1.0.0 now in beta - aaw
http://bestinclass.dk/index.clj/2010/11/clojureql--1.0.0-now-in-beta.html
======
andreas_bak
I can not understand what problem this library solves ? Why to write SQL in
Clojure and translate it back to SQL ?

Examples on website are quite simplistic. They are far away from real life SQL
queries that usually bigger and more complex (not select and join couple of
tables). What about "group by", joining 5 or 8 tables etc.? How you are
supposed to prototype and test your queries on existing schema (there are many
good graphical clients for many RDBMSes)? There are many questions remaining
unanswered.

At least Clojre-QL do not try to fit a square peg into round hole like
Hibernate. Personally I liked Hibernate for some period, until I sat down and
learned to use SQL.

~~~
swannodette
I suggest you read this post and its comments:
[http://magicscalingsprinkles.wordpress.com/2010/01/28/why-i-...](http://magicscalingsprinkles.wordpress.com/2010/01/28/why-
i-wrote-arel/)

~~~
andreas_bak
I read the article. The guy claims that SQL is hard -- yes it is hard for real
life cases and there are limitations imposed by underlying theory (relational
algebra). Joining the table with itself may be little mind-blowing when you do
it first time. It still does not mean that we need to write queries in
different language and translate them back to SQL.

A simple question is "how the hell you use prepared statements with such
libraries"? And the answer will be is that the FRAMEWORK need to be extended
further in order to support them. In other words once you abandon SQL you will
never have the same flexibility that it gives, because of artificial
constraints imposed by every framework. And your code will become more and
more complex because of all these frameworks that are invented not of the real
need but as an programming exercise.

~~~
swannodette
I suggest you read this article,
[http://www.joelonsoftware.com/articles/LeakyAbstractions.htm...](http://www.joelonsoftware.com/articles/LeakyAbstractions.html)

~~~
andreas_bak
I am not against new ways of querying RDBMSes but until today SQL seems the
most simplest and clean way to do it. Most realistic solution will be not to
abstract SQL but develop a new query language for relational datasources (on
same level with SQL). I am pro abstractions that simplify things (like TCP)
and against naive abstractions ignoring the basic aims of layers under. TCP
simplifies things, Clojure-QL complicates them.

PS: The article that you suggested is written by a guy that tend to speculate
over his point of view without taking in account the reality. In all modern
RDBMSes queries having (a=b and a=c and b=c) will be simplified by query
planners (Oracle and Postrgre do it) so there will not be any difference in
performance.

------
peregrine
I've been looking for something similar to this! Having just learned of
Relational Algebra in class I've always wondered why we went with a more
difficult to understand abstraction of SQL.

~~~
swah
I wrote my web app DB access in pure SQL and I'm thinking if its worth a
rewrite with something like this. Initially I thought I could "abstract" SQL
with a few functions of mine, but that was very short-sighted thinking.

------
constant_change
I've been waiting for this rewrite! By the looks of this page, you've done a
fine job. Excellent work team ClojureQL! I'm looking forward to giving it a
test run.

------
sandGorgon
MySQL only

Which is why I'm still using Oyako (<https://github.com/briancarper/oyako>)

~~~
ninjudd
ClojureQL works fine with postgresql or any other database supported by JDBC.

~~~
oddthink
Is there a way to tell it to use different syntax for take/drop for databases
(like Sybase) that use the "select top X * from foo" syntax rather than
"select * from foo limit X"?

~~~
lbj
Not yet. Currently we try to follow the SQL standard as closely as possible,
but some operations like OFFSET/LIMIT provide challenges.

Would be fun to see if we could do some kind of SQL templating where users
could supply their own templates.

------
rapind
This looks pretty sweet. Can't wait to try it out.

