I’ve been observing OneWebSQL™ for a year now, impatiently expecting its first public version and official go-live. I first discovered it during my regular jOOQ marketing work. I’m always closely observing competition for several reasons:
- It shows that the market is alive and active, which helps making jOOQ even more relevant
- jOOQ can incorporate the best ideas of competitor products
- It’s always fun to meet people who share similar opinions
All of the above is a big motivation to make jOOQ better. For more competitor comparisons, see also the following recent articles:
- jDBI: A simple convenience layer on top of JDBC
- jOOQ compared to iBatis
- Liquibase for DB Migrations
- MentaBean, the ORM/SQL Builder of Mentawai
- iciql, a fork of H2′s JaQu
- The Avajé Ebean Framework and asynchronous query execution
- The Ollin Framework
OneWebSQL™
OneWebSQL™ is one of the more interesting ones, from a professional perspective. Similar to QueryDSL, OneWebSQL™ is backed by a company who has developed a SQL code generation and execution framework over the past years. Unlike jOOQ and QueryDSL, however, OneWebSQL™ is neither free nor open source. So lets have a brief look at what OneWebSQL™ is and how it compares to jOOQ and QueryDSL
Comparing jOOQ, QueryDSL, OneWebSQL™
The below list of compared features and attributes is meant to be objective and unbiased, even if it was written by the developer of jOOQ. Here goes
License
| jOOQ | ASL 2.0, free and open source |
| QueryDSL | ASL 2.0, free and open source |
| OneWebSQL™ | Proprietary license, closed source and partially obfuscated. Free runtime, somewhat expensive source code generator |
Vendor and community
| jOOQ | Independent developer, active community |
| QueryDSL | Mysema, active community |
| OneWebSQL™ | e-point, newcomer with undisclosed community |
Scope
| Feature | jOOQ | QueryDSL | OneWebSQL™ |
|---|---|---|---|
| Source code generation [1] | yes | yes | yes |
| Active Records [2] | yes | partially (through JPA) |
partially (through generated DAOs) |
| Procedure support [3] | yes | no | partially (some JDBC abstraction) |
| UDT support [3] | yes | no | no |
| DSL [4] | yes (formal BNF notation) |
partially (chained methods) |
partially (chained methods) |
| DML support | yes | yes | yes |
| DDL support | no | no | no |
| Supported RDBMS | 13 | 9 (or more, using JPA) |
5 |
| SQL dialect abstraction [5] | yes | yes | partially (simulates some syntax elements) |
| SQL dialect simulation [6] | yes | yes | no |
| Scala examples [7] | Partially Proof of concept |
Partially Proof of concept |
Probably (?) |
Some explanations
- [1]: jOOQ and QueryDSL can reverse-engineer database meta data directly from a database. OneWebSQL™ expects a proprietary model file
- [2]: “Active Records” are record classes that can persist (store, refresh, delete) themselves or be passed to an EntityManager, DAO, etc for persistence.
- [3]: Stored procedures (and especially functions) can be used directly in SQL
- [4]: A domain-specific language is best defined using a BNF notation. This can be translated to Java interfaces as described in a recent blog post. Simpler fluent APIs can still be constructed using “chained methods”. Strictly speaking, that is not a domain-specific language, though
- [5]: SQL dialects vary greatly in subtle ways. Any SQL building tool should be able to distinguish dialects. This blog contains many examples, such as RDBMS bind variable casting madness
- [6]: Many syntax elements (and more specifically functions) can be simulated in dialects that do not natively support them. This blog contains many examples, such as The simulation of TRUNC() in Derby
- [7]: All Java libraries can be used in Scala, even without any native API.
Conclusion
The above comparison was made at a high level. Without further knowledge of the specific needs for any given project, it doesn’t make sense to go into the details of every library’s capabilities. On a high level, one can draw a clear line between the three products:
jOOQ
jOOQ’s strength is the fact that it supports a huge variety of standard and vendor-specific SQL statements, clauses and functions, and that it is able to simulate these in dialects that do not support them. This makes jOOQ a good choice for applications that want to make extensive use of SQL.
QueryDSL
QueryDSL’s strength is the fact that it supports multiple backends (most importantly JPQL and HQL). It greatly facilitates the construction of criteria queries, reducing JPA’s verbosity.
OneWebSQL™
OneWebSQL™’s strength is probably the fact that you get professional support when you buy a license. I’m looking forward to hearing experiences with this new library