Author here. It's funny, I actually didn't even know about HoneySQL when I made this. It was only after that someone pointed it out to me that I saw how similar our libraries are.
It believe it says something really good about this approach that we both came to such a similar conclusion independently.
I think OJ takes a slightly more minimalistic approach. I would say that my specification is a little more precise as well. Maybe in the future the author of HoneySQL and I can collaborate.
+1 - This is by far the sanest approach to rdbms interaction I've seen. It's kind of sad that we're stuck with SQL but while we're stuck with it we should stick to it. :P
I agree and it's what I've used for all of my pet clojure projects that need to talk to a database. However, the drawback it suffers versus a lot of the approaches taking by most of the alternative libraries is that it doesn't provide any way to compose queries.
I'm talking about the kind of stuff something like Korma or SQLAlchemy enable where you build up a query to be executed dynamically based on, for example, user filters.
I haven't need anything like that on any of my pet projects so I've been deliriously happy with Yesql. But, while working on those pet projects I do often find myself thinking about whatever I'm doing in my day job and I haven't come up with a good way to support composability within the context of Yesql. I would love to see a solution to that.
It believe it says something really good about this approach that we both came to such a similar conclusion independently.
I think OJ takes a slightly more minimalistic approach. I would say that my specification is a little more precise as well. Maybe in the future the author of HoneySQL and I can collaborate.