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.
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.
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 :)
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...").
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:
