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
