This is a guest post by Lukas Eder, the creator of jOOQ open source Java API for typesafe SQL modeling. If you develop or use an open source application and would like to tell the world about it, CUBRID open source database project is accepting guest posts.
Big Data, the Web and SQL
In recent years, software companies have started to raise millions up to billions of dollars getting acquired by a big player, such as Google, Facebook, Yahoo! or Microsoft. Very often, the assumed value of such deals lay in the fact that Big Data could be purchased along with such acquisitions. "Social" Big Data was generated by millions of users over the web. It seemed too big to fit in classic relational databases, which is why the purchases also included buying the proprietary, rather short-lived technologies used to maintain Big Data. Most of the new companies thus experimented with NoSQL in one form or another.
SQL, on the other hand, has come a long way. SQL is a very expressive and powerful language used to model queries against any type of data, albeit mostly relational. At the same time, SQL is standardised and quite open. CUBRID is a good example of an object-relational database, which combines the expressiveness of SQL with high availability, sharding, and many other features needed to manage Big Data! In other words, CUBRID is the proof that SQL can be an adequate technology for the modern web.
Querying CUBRID with jOOQ
jOOQ is a Java API modelling SQL as an internal domain-specific language directly in Java. It features a built-in code generator to generate Java classes from your database model. These generated classes can then be used to create typesafe SQL queries directly in Java. A simple example of how this works with CUBRID can be seen in this jOOQ CUBRID tutorial.
The idea of creating fluent APIs in Java is not new. Usually, Martin Fowler takes most credits for his elaborations on the subject. After that, many approaches towards building internal domain-specific languages have surfaced, mostly in unit testing environments (e.g. JMock and Mockito). Apart from jOOQ, there are also a couple of fluent APIs that model SQL as a language in Java. These include:
Among the above, QueryDSL is the only other API with a comparable traction to jOOQ's. While QueryDSL hides the full SQL expressiveness behind a LINQesque API, jOOQ strongly focuses on SQL only. Unlike any of the above SQL abstraction APIs, jOOQ combines these features:
A BNF defines jOOQ's fluent API
jOOQ uses next generation techniques to implement its fluent API. These techniques involve a formal BNF notation specifying API type and method hierarchies:
With a formal BNF, jOOQ's fluent API is much more robust and typesafe, as it will dictate syntax correctness in a more formal way than ordinary builder APIs.
jOOQ embraces usage of stored procedures
When closely coupling with your favourite relational database, you will likely want to make use of stored procedures and functions, directly in your SQL. jOOQ embraces this fact and allows for typesafe embedding of stored functions.
jOOQ embraces usage of row value expressions
Row value expressions (also called tuples, records) are at the heart of SQL. Few libraries outside of the SQL world will be able to model the fact that the following predicates are type-safe:
-- Types must match: ^^^^ ^^^^
SELECT * FROM t1 WHERE (t1.a, t1.b) IN (SELECT t2.a, t2.b FROM t2)
-- Types must match: ^^^^^^^^^^^^ ^^^^^^^^^^
SELECT t1.a, t1.b FROM t1 UNION SELECT t2.a, t2.b FROM t2
-- ^^^^^^^^^^ Types must match ^^^^^^^^^^
jOOQ will leverage the Java compiler to help you check the above:
// Type-check here: -----------------> ^^^^
select().from(t1).where(row(t1.a, t1.b).in(select(t2.a, t2.b).from(t2)));
// Type-check here: ----------------------------> ^^^^^^^^^^
select(t1.a, t1.b).from(t1).union(select(t2.a, t2.b).from(t2));
// Type-check here: -------------------> ^^^^^^^^^^
jOOQ emulates built-in functions and SQL clauses
Providing support for simple SQL clauses is easy: SELECT, DISTINCT, FROM, JOIN, GROUP BY, etc. Implementing "real" SQL is much harder, though. Take the above row value expressions, for instance. They are currently not supported in CUBRID, but you can use them nonetheless with jOOQ. jOOQ emulates missing functions and SQL clauses for you as can be seen in this syndicated blog post.
jOOQ renders specialised SQL for 14 major RDBMS vendors
Instead of generalising and abstracting advanced standard and vendor-specific SQL features, such as JPA and tools built upon JPA, jOOQ sees good things in each vendor-specific syntax element. You know your database well, so you want to leverage it, not abstract it.
jOOQ is a platform
jOOQ is much more than just a SQL library. For example, it features the very useful jOOQ Console, which helps you debug and profile your jOOQ-generated SQL statements in any environment, without the need for expensive third-party tools:
The jOOQ Console also includes on-the-fly SQL editing tools as well as breakpoint capability for advanced debugging.
More feature comparisons
More feature comparisons can be found here, in this blog post.
Getting productive with jOOQ
jOOQ is a vision where SQL matters again to the Java developer. While some have called ORM to be the Vietnam of Computer Science, jOOQ is the Peace Treaty Between SQL and Java. Using the above and many more features, you can be productive again when writing high-performing, specialised SQL against your favourite database directly in Java, typesafely compiled by your Java compiler.
By Lukas Eder, the creator of jOOQ. Follow him on Twitter @JavaOOQ.
I'm a Java and SQL enthusiast developer currently contracting for Adobe Systems in Basel, Switzerland. Originating from the E-Banking field, I have a strong Oracle SQL background. I'm the creator of jOOQ, a comprehensive SQL library for Java.