No problem Luke. ClojureQL does not take the backend in to account. This is the one feature from the old CQL that I didn't want to carry over because it would be impossible for me to cater to all backends. If you hit specific problems, let me know and I'll see what we can do.
We adhere to SQL92 and test everything on MySQL and Postgres. If you're in a situation where thats not good enough, its always possible to supply part of your expression as a string. I just implemented the final piece before 1.0.0 FINAL today, which is a predicate compiler that captures the environment and automatically paramterizes all predicates. To help spread such lightweight news snippets Ive put up this tumblr in case anybody's interested: http://laujensen.tumblr.com Lau On Nov 24, 9:31 pm, Luke VanderHart <luke.vanderh...@gmail.com> wrote: > Thanks... I think I do see the benefit. I'll certainly give it a try > and see if I can get the feel of it. > > One question... You say it generates optimized SQL. Does it take the > DBMS into account? I know the performance profiles of various SQL > idioms vary widely between MySQL and Oracle, for example - what may be > better as a subselect on one may sometimes be better as a join on > another. > > Thanks so much for the detailed answer... > > -Luke > > On Nov 24, 3:37 am, LauJensen <lau.jen...@bestinclass.dk> wrote: > > > Hi Luke, > > > Thanks! > > > Initially CQL0.1 was motivated by "everything in Clojure" which was > > the driving design principle behind the first version of CQL. When > > I scrapped that project (for reasons you can read on my blog) I > > instead turned my attention towards Relational Algebra as this > > gives you unique ways to compose and express your queries, in > > my opinion far superior to the SQL language itself. > > > Example from our test suite: Lets say you want to define a table > > which computes an aggregate on a column, ex counting pictures > > by user id and then join those stats to your users table. In CQL > > you will (hopefully) intuitively write: > > > (let [photo-counts (-> (table :photos) > > (aggregate [[:count/* :as :cnt]] > > [:id])))] > > (-> (table :users) > > (join photo-counts (= {:users.id :photos.id})) > > > I think thats really as simple as you can express that join operation. > > However for the SQL to work/be efficient, you need to detect when > > a join benefits from spawning subselects and ClojureQL handles this > > for you completely transparently, so if you execute the above > > statement > > the following is actually generated and run: > > > "SELECT users.*,photos_aggregation.cnt FROM users > > LEFT OUTER JOIN > > (SELECT photos.user_id,count(photos.*) AS cnt FROM photos GROUP BY > > user_id) > > AS photos_aggregation ON (users.user_id = photos_aggregation.user_id)" > > > And notice how your reference to :id in photos is automatically > > aliased > > to photos_aggregation. There are SQL statements which are truely > > complex > > and it takes a long time to master SQL and get comfortable with such > > queries. > > It is my ambition that ClojureQL will take away that complexity while > > still > > generating the most efficient SQL statements possible. The > > implications for > > Q/A on your projects will be substantial I hope. > > > And even if I was only doing CRUD - I'd prefer to do it (and have my > > developers do it) > > in Clojure, which is guaranteed to compile to correct SQL. > > > Answers your question? > > > Lau > > > On Nov 24, 1:56 am, Luke VanderHart <luke.vanderh...@gmail.com> wrote: > > > > Lau, > > > > This is really impressive, and I can't wait to experiment with it. > > > > That said, I'm curious as to what good use cases for this would be, > > > and what it's motivation is. SQL is already a highly specialized DSL > > > for slinging around relational data that most developers are already > > > pretty good with. I'm wondering how useful it is to have a separate > > > relational DSL. Is this motivated by the same "everything in Clojure" > > > philosophy (like Hiccup or Scriptjure)? Not that there's anything > > > wrong with that... I'm just curious as to use cases. > > > > Or does it confer some other benefit over SQL besides being Clojure? > > > The only thing I see is the ability to reuse and compose fragments of > > > relational logic. Unarguably, that is very cool, but off the top of my > > > head I can't think of any particular benefit it would give, at least > > > in my apps. 99% of my database interaction is a fixed set of CRUD > > > operations, which (unless I'm missing something) would be just as easy > > > to write in SQL directly. > > > > Thanks, > > > -Luke > > > > On Nov 18, 2:10 pm, LauJensen <lau.jen...@bestinclass.dk> wrote: > > > > > Hi gents, > > > > > For those of you who have followed the development > > > > of ClojureQL over the past 2.5 years you'll be excited > > > > to know that ClojureQL is as of today being released > > > > as 1.0.0 beta1. > > > > > That means that the significant primitives from Relational > > > > Algebra are all in place and functional. The documentation > > > > is there and I've even made a screencast in order to get > > > > you guys started. > > > > > Personally Im excited about this version because it really > > > > does change the way you work with a database. Queries > > > > are incredibly composable! > > > > > For more information, please checkout this blogpost + > > > > screencast:http://bestinclass.dk/index.clj/2010/11/clojureql--1.0.0-now-in-beta.... > > > > > Best regards, > > > > Lau -- 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
