This morning, we’ve had very nice feedback about our work on the jOOQ User Group by Ben Hood, who has been a long-time jOOQ user and ideas/bug report contributor. He has taken inspiration from our software to build CQLC, a fluent API / query DSL for Cassandra’s CQL written in Go. Citing Ben:
I think JOOQ is the best thing since sliced bread when it comes to dealing with SQL databases on the JVM. I’ve been writing some CQL based apps in Go, and I’ve really missed JOOQ. So I decided to build a JOOQ for Go/Cassandra.
cqlc generates Go code from your Cassandra schema so that you can write type safe CQL statements in Go with a natural query syntax.
It’s aimed at people using CQL in Golang apps who are looking to reduce boilerplate code. […] I think it reinforces the pragmatism of the underlying concept behind JOOQ.
The project is available here:
I’ve written a blog post to explain what motivated me to do this here:
That’s great news for Cassandra and CQL! NoSQL databases will not profit from jOOQ directly any time soon – unless they implement actual SQL. We have studied Cassandra’s CQL syntax in the past and we’ve come to the conclusion that formal jOOQ support would be overkill, similar to JCR-SQL2 support or CMIS SQL support. 90% of the jOOQ API wouldn’t work.
So if your a Go developer using Cassandra, do have a look at CQLC!
6 thoughts on “Introducing CQLC – a Query DSL for Cassandra’s CQL in Go, Inspired by jOOQ”
Next thing you know, you’ll see it with MongoDB.
Yes, let’s hope so! Maybe you have some spare time to contribute a fluent API to MongoDB? Maybe, you can even sell it to 10gen, if it’s well done…
But then MongoDB is shema-less, and JOOQ DSL is generated from a fixed schema. Even if the query language is less expressive than SQL, you can make use of Spring Data Mongo to abstract it a little bit.
Why don’t the MongoDB guys implement a better query language? I mean, this JSON thing, that’s not really the answer to anything, I suppose?
It seems there are SQL-MongoDB adaptors:
A solution like Apache Hive for MongoDB would be more than useful. The reason I like JPQL or HQL is because they mime SQL, so you don;t actually have to “learn them”, you know them already.
Well… Given the amount of frustration I’ve had with my short JCR-“SQL”-2 intermezzo, realising every 10 seconds that they’re missing this feature, that feature, etc… The SQL standard has 1500 pages of awesomeness. Implementing only 10-15 pages is like saying