5 ms·

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

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 16y ago
I suggest you read this post and its comments: http://magicscalingsprinkles.wordpress.com/2010/01/28/why-i-wrote-arel/ http://magicscalingsprinkles.wordpress.com/2010/01/28/why-i-...
- andreas_bak 16y ago
  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 16y ago
    I suggest you read this article, http://www.joelonsoftware.com/articles/LeakyAbstractions.html http://www.joelonsoftware.com/articles/LeakyAbstractions.htm...
    - andreas_bak 16y ago
      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.
    - binomial 16y ago
      Idea: Bot which automatically gives relevant replies to comments, using NLP, sentiment analysis and web search to find relevant links. It would only reply if it's certain enough that the link it wants to suggest is relevant enough and has a dissenting opinion relative to the comment as well as decent pagerank/social-media-rank.
abscondment 16y ago
Clojure code is Clojure data. So, these SQL statements are really just nested lists. Instead of writing an ad-hoc SQL parser and doing string manipulation, you can write relatively simple Clojure functions to manipulate these lists and generate valid SQL.
- andreas_bak 16y ago
  1. Why to write an ad-hoc sql parser in Clojure. The result of query is a JDBC ResultSet (on JVM). You may define some functions that transform rows from ResultSet to Clojure terms in order to make your code shorter. 2. They are not simple functions. Compare this : (-> (select (table {} {:employees :p})(where (= :name "John")))(join (table {} {:employees :b})(where (= :p.manager :b.id)))to-sql) to this : SELECT p.,b. FROM employees p JOIN employees b ON (p.manager = b.id) WHERE (name = 'John') Which one is more verbose ? EDIT: SQL examples with "employees" and "departmets" are very misleading and usually oversimplify the reality.
  - swannodette 16y ago
    But your missing the point. You can store parts of queries and reuse them, recombine them however you see fit: (def users (cql/table db :users)) (def photos (cql/table db :photos)) (def users-and-photos (cql/join users photos (cql/where (= :users.id :photos.user_id)))) (def photo-titles (-> users-and-photos (cql/project #{:photos.title}))) Note that my queries just keep getting smaller and smaller ;) By writing the mundane portions of your SQL queries again and again by hand you will have more duplication.
    - andreas_bak 16y ago
      Yes I agree. But, I believe that it is just a perversion. In any project that involves RDBMS writing queries is just a small part of development. Surely you could modify queries with Clojure-QL (with SQL it will be a suicide) but what you gain from it ??? (more free time - I don't think so). Furthermore, having such dynamic "meta-"things in your code, eventually will cost you more time in debugging it. With SQL it is straight-forward: you prototype your query using some GUI client and then you just embed it in your program. How it can be done with Clojure-QL ?
lancepantz 16y ago
ClojureQL forms are composable abstractions. One can let a clojureql query, execute it, do x with the results, add a where clause and get back another set of results-- all without any code repetition.
wilkes 16y ago
I suggest watching the screencast. It has examples of some pretty complex queries including aggregating and group by.

swannodette 16y ago

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

andreas_bak 16y ago
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 16y ago
  I suggest you read this article, http://www.joelonsoftware.com/articles/LeakyAbstractions.html http://www.joelonsoftware.com/articles/LeakyAbstractions.htm...
  - andreas_bak 16y ago
    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.
  - binomial 16y ago
    Idea: Bot which automatically gives relevant replies to comments, using NLP, sentiment analysis and web search to find relevant links. It would only reply if it's certain enough that the link it wants to suggest is relevant enough and has a dissenting opinion relative to the comment as well as decent pagerank/social-media-rank.

abscondment 16y ago

Clojure code is Clojure data. So, these SQL statements are really just nested lists. Instead of writing an ad-hoc SQL parser and doing string manipulation, you can write relatively simple Clojure functions to manipulate these lists and generate valid SQL.

andreas_bak 16y ago
1. Why to write an ad-hoc sql parser in Clojure. The result of query is a JDBC ResultSet (on JVM). You may define some functions that transform rows from ResultSet to Clojure terms in order to make your code shorter. 2. They are not simple functions. Compare this : (-> (select (table {} {:employees :p})(where (= :name "John")))(join (table {} {:employees :b})(where (= :p.manager :b.id)))to-sql) to this : SELECT p.,b. FROM employees p JOIN employees b ON (p.manager = b.id) WHERE (name = 'John') Which one is more verbose ? EDIT: SQL examples with "employees" and "departmets" are very misleading and usually oversimplify the reality.
- swannodette 16y ago
  But your missing the point. You can store parts of queries and reuse them, recombine them however you see fit: (def users (cql/table db :users)) (def photos (cql/table db :photos)) (def users-and-photos (cql/join users photos (cql/where (= :users.id :photos.user_id)))) (def photo-titles (-> users-and-photos (cql/project #{:photos.title}))) Note that my queries just keep getting smaller and smaller ;) By writing the mundane portions of your SQL queries again and again by hand you will have more duplication.
  - andreas_bak 16y ago
    Yes I agree. But, I believe that it is just a perversion. In any project that involves RDBMS writing queries is just a small part of development. Surely you could modify queries with Clojure-QL (with SQL it will be a suicide) but what you gain from it ??? (more free time - I don't think so). Furthermore, having such dynamic "meta-"things in your code, eventually will cost you more time in debugging it. With SQL it is straight-forward: you prototype your query using some GUI client and then you just embed it in your program. How it can be done with Clojure-QL ?

lancepantz 16y ago

ClojureQL forms are composable abstractions. One can let a clojureql query, execute it, do x with the results, add a where clause and get back another set of results-- all without any code repetition.

wilkes 16y ago

I suggest watching the screencast. It has examples of some pretty complex queries including aggregating and group by.