

Korma: Tasty SQL for Clojure - davesims
http://sqlkorma.com/

======
icey
Previously: <http://news.ycombinator.com/item?id=3188609>

~~~
zeratul
Do we know how many days need to pass before it's possible to re-post exactly
same URL? It seems to me that HN has a ton of undocumented features.

~~~
icey
I don't know, but I also don't know if it's really worth worrying much about.
If something gets posted too many times, people will either flag it, or just
won't upvote it.

~~~
zeratul
This might cause unintended consequences for the HN button:

<http://hnapiwrapper.herokuapp.com/>

For example, I'm using one for my app:

[http://hnapiwrapper.herokuapp.com/button.html?width=120&...](http://hnapiwrapper.herokuapp.com/button.html?width=120&url=http://hnpickup.appspot.com/&title=When%20is%20good%20time%20to%20submit%20a%20story%20on%20HN?#)

I wander if it will cause the button to reset after 19 days if someone clicks
it.

------
Zak
I'd really like to see a detailed comparison to ClojureQL, which I'm currently
using on a couple projects. I've been using ClojureQL in a project and so far
have found it pretty satisfactory, but I've been wishing for something like
Korma's entities.

I'd also like to see a rationale from the author, much like Clojure itself
has. Why write this when ClojureQL exists? If entities are the only reason,
why not write them as an addon? To be clear, these are honest questions I'm
curious about, not rhetorical arguments against Korma.

~~~
ibdknox
There are lots of reasons, but I think the most convincing ones are these:

1) ClojureQL is an attempt at a high level abstraction that isn't built on a
useable base.

2) ClojureQL generates inefficient (and sometimes nonsensical) SQL

3) It isn't "simple", both in implementation and conception

I'll tackle these in order.

ClojureQL abstracts SQL away as relational algebra, but sometimes what you
really need is just SQL. As it stands, you can usually find ways to generate
the SQL you want, but to do so, you have to leave the abstraction behind. Such
a "leak" indicates to me that what is really needed here is that first level
of abstraction - the one that represents SQL directly. As a matter of fact, I
believe that ClojureQL should be built _on top_ of Korma. Were that the case,
the abstraction would flow cleanly upward and when you needed to interact
directly with SQL it would be obvious and very clean to do so. Beyond that, I
think ClojureQL presents the wrong general abstraction, but that's more of an
opinion than anything.

As a result of trying to hide SQL, ClojureQL has to create queries in a
certain way to handle most cases transparently. This often leads to unusual
SQL and anyone who has looked at the output knows that ClojureQL uses tons of
subselects that are inefficient and simply unnecessary.

SQL is already an abstraction over relational data and people are already
comfortable with it. The simplest interface you can present to someone is
something that maps directly to SQL - and that's what Korma does. Beyond that,
look at the implementation of Korma vs. the implementation of ClojureQL. Korma
provides simple and very powerful composability by adhering to the notion that
all you're doing is modifying data that ultimately gets fed into a SQL
generator. What this allows in the end is infinite reconfigurability. Want a
completely different way of generating your queries? Go ahead and build it on
top of Korma. As others have suggested, you can think of the library as a sort
of Ring for SQL - it provides the base for virtually anything to be built on
top of. It also, however, provides some higher-level bits that make working
with SQL so much easier. Entities, for example, make it easy for those coming
from other languages/frameworks simply due to familiarity.

I built Korma to fill the gap and I believe that ClojureQL and Korma are
fundamentally at different levels. In the end, this opens up the potential for
_new_ , very lightweight, higher level abstractions... and that's what I'm
excited to see :)

~~~
andrewcooke
do you have evidence that subselects are inefficient? (i don't know the answer
myself - i would hope that a database can do pretty decent optimisation, but
perhaps this is the db equivalent of "given a sufficiently good compiler...").

~~~
ibdknox
It depends very heavily on which RDBMS you use as to what ends up optimized.
It's a relatively well trafficked subject, a simple google search turns up
quite a few results, for example:

[http://www.mysqldbahelp.com/2010/03/subselect-vs-join-
perfor...](http://www.mysqldbahelp.com/2010/03/subselect-vs-join-
performanace.html)

Disclaimer: I didn't validate his results ;)

------
zyfo
It was posted less than a month ago. There's no major new release. Please
search before submitting.

~~~
Zak
I hadn't heard of it until today, so I'm glad it was reposted.

