cqlc: Kudos to JOOQ

[Ben Hood]

Hi,

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 - most people on this list will probably never
need this tool, but I think it reinforces the pragmatism of the
underlying concept behind JOOQ.

The project is available here:

http://relops.com/cqlc/

I've written a blog post to explain what motivated me to do this here:

http://relops.com/blog/2014/01/25/cqlc/

Much kudos goes to Lukas for the concept of JOOQ and the principles he
has followed of letting the database do what it does best - these
principles have all flown into cqlc.

Cheers,

Ben

[Lukas Eder]

Hi Ben,

This is great! Thanks for letting us know, and thanks for your nice words.

Yes - NoSQL databases will not profit from jOOQ directly any time soon - unless they implement actual SQL. I have studied Cassandra's CQL syntax in the past and I've come to the conclusion that formal jOOQ support would be overkill, similar to JCR-SQL2 or CMIS SQL. 90% of the jOOQ API wouldn't work.

So your new API is great news for the Cassandra community! I will cite your mail on the jOOQ blog and advertise your CQLC - I'm sure you won't mind :-)

Cheers

Lukas

2014-01-27 Ben Hood <0x6e...@gmail.com>

--
You received this message because you are subscribed to the Google Groups "jOOQ User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jooq-user+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Ben Hood]

Hey Lukas,

Many thanks for the great publicity - very much appreciated :-)

I fully agree with your point about JOOQ and NoSQL. Depending on what
particular problem you are trying to solve, a SQL database or a NoSQL
database might be a better tool for the job. If the former is the case
and you have a JVM app, then you are right in JOOQ's sweetspot.

I think in most cases, the query semantics of NoSQL databases are not
declarative enough to be subsumable by a variant of the JOOQ API. Were
you to attempt this, I think you'd run into the issue that Joel
Spolsky calls a leaky abstraction.

In the case of Cassandra/CQL you have an interesting half-way house:
CQL is still far off being SQL in terms of functional richness, and
because of that, you would still lose 90% of JOOQ. But, CQL does place
a little bit of SQL-esque structure on top of the raw Cassandra data
model, and there are a bunch of scenarios where valid CQL can lead to
invalid data access patterns. So that's why I wanted to cherry pick
JOOQ's compile time ability to detect illegal query constructs in CQL.

So I think the rule of thumb is too pick the right tool for the job,
use tools that keep you productive and let the database do the heavy
lifting for you.

As an aside, I'm currently working on JOOQ based project which hasn't
been released yet, so I'm still going to be a user of JOOQ for some
time to come.

Cheers,

Ben

[Lukas Eder]

Hi Ben,

2014-01-27 Ben Hood <0x6e...@gmail.com>

Hey Lukas,

Many thanks for the great publicity - very much appreciated :-)

I fully agree with your point about JOOQ and NoSQL. Depending on what
particular problem you are trying to solve, a SQL database or a NoSQL
database might be a better tool for the job. If the former is the case
and you have a JVM app, then you are right in JOOQ's sweetspot.

I think in most cases, the query semantics of NoSQL databases are not
declarative enough to be subsumable by a variant of the JOOQ API. Were
you to attempt this, I think you'd run into the issue that Joel
Spolsky calls a leaky abstraction.

Well, we'll see. I tend to think that NoSQL folks will realise that the SQL language is very well suited for most problems. I usually cite Mark Madsen in this context :-)

http://www.nosql-vs-sql.com/#no-tation

Of course, the above marketing website is not to be taken too seriously... (before I trigger another flame-war)

 

In the case of Cassandra/CQL you have an interesting half-way house:
CQL is still far off being SQL in terms of functional richness, and
because of that, you would still lose 90% of JOOQ. But, CQL does place
a little bit of SQL-esque structure on top of the raw Cassandra data
model, and there are a bunch of scenarios where valid CQL can lead to
invalid data access patterns. So that's why I wanted to cherry pick
JOOQ's compile time ability to detect illegal query constructs in CQL.

Absolutely!

 

So I think the rule of thumb is too pick the right tool for the job,
use tools that keep you productive and let the database do the heavy
lifting for you.

As an aside, I'm currently working on JOOQ based project which hasn't
been released yet, so I'm still going to be a user of JOOQ for some
time to come.

Great! Looking forward to more feedback!

Cheers

Lukas

[Ben Hood]

On Mon, Jan 27, 2014 at 10:56 AM, Lukas Eder <lukas...@gmail.com> wrote:
> Well, we'll see. I tend to think that NoSQL folks will realise that the SQL
> language is very well suited for most problems.

I'm not claiming to be an architect, but FWIW I'm working on an app
where some of the data is storage and queried in Cassandra and some
stored and queried in Postgres. I just didn't feel like compromising,
so I used both.

> I usually cite Mark Madsen
> in this context :-)
> http://www.nosql-vs-sql.com/#no-tation
>
> Of course, the above marketing website is not to be taken too seriously...
> (before I trigger another flame-war)

:-)

Given my previous statement, I'll quite happily sit on the fence. But
use JOOQ when dealing with SQL :-)

[Lukas Eder]

2014-01-28 Ben Hood <0x6e...@gmail.com>

Good :-)