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
Wow, I can’t believe 1) someone would think they can sell an ORM as a product these days and 2) that other people would buy it (I assume, anyway).
Maybe I am underestimating the value some developers/managers would put on professional support.
That being said, I have wondered at times, having put a lot of time and effort into Joist, as I’m sure you have with jOOQ, whether there is a way for open source developers to make money from their projects without becoming Redhat.
In that regard, I have no problems with OneWebSQL’s capitalistic motivations, I’m just disappointed they’re using a 1990s license model instead of some kind of innovative open source + commercial model.
Stephen, great to get in touch with you! I was going to write an article about joist very soon anyway. I’ve found it being referenced a couple of times in the web. Perhaps, you could tell me where you got the term “shims” from :-)
I agree with you, I was surprised to see such a license and price on this product. Apart from the DAO generator (which I was going to add to jOOQ soon anyway), I don’t see many new things in OneWebSQL™ compared to competing products. On the other hand, with Hibernate / velocity, I imagine it is quite easy to generate those DAO’s manually.
So my hypothesis was really that the commercial support must be the thing that e-point is trying to sell here. From what I’ve learnt so far, e-point customers already use OneWebSQL productively. I don’t mind “capitalism” in this business. In the end, end-users are mature enough to make proper decisions and use the right tool for the right purpose. I hope, at least…
> I was going to write an article about joist
Awesome!
> where you got the term “shims”
I must take the credit/blame for making that up. I guess a traditional shim can be used to open doors/get you into places (I guess? I might be stretching the definition), so I was thinking of Joist’s shims as how the ORM reached into the private fields of the domain objects without using reflection or the public getters/setters (which might have business logic in them).
> with Hibernate/velocity, I imagine it is quite easy to generate those DAO’s manually
Agreed; Joist is the v2/complete rewrite of an internal project that used Hibernate + Velocity-generated domain objects. It’s really not that hard if you stick to the basic things and avoid being too fancy.
Looking more at OneWebSQL, I have a few nits: they don’t support inheritance, nor writing custom business logic in your domain objects. And, while I very much share their primary motivation (generating your domain/DAO layer), it just feels slightly off. Perhaps I’m just too used to domain objects instead of DAOs.
That being said, they have really great docs. Lots of them and they look and read great.
> shims
OK, I will cite your explanation about shims. That’s really an odd concept by which to name a feature ;-)
> DAOs
It always depends whether your preferred paradigm is “data-centric” or “domain-centric”. With a data-centric paradigm, inheritance is not needed, as you probably want to have a somewhat relational data model also in Java. DAOs can be useful for that. If you go the other way round, mapping your inheritance to outer joins, then you probably don’t need DAOs. But these things are a matter of taste…
> docs
Yes, the OneWebSQL documentation is really well-written and well-structured!
Hi Lukas!
Thanks for your review. It’s nice that you’ve found some time to check our product.
Regarding the commercial value of OneWebSQL, we want to be one stop shopping place for programming database layer in Java. Fluent API by itself is not enough. Code generation by itself is not enough. Graphical database modeling by itself is not enough. What you need is a reliable, well documented *development process* that binds all these together. Take notice that all projects in our space silently ignore this issue. Graphical database modeling support is especially weak – there are no really good open source modeling tools and, as far as I’m aware, no open source Java ORM integrates directly with any graphical database modeler. In contrast, OneWebSQL provides tools, support and the documentation for all three parts of the process. Nice to know that you liked our docs :)
As with any commercial endeavor we hope to make money from OneWebSQL. Yes, you can use open source tools, glue them together and google for any possible problems but, paraphrasing Jamie Zawinski, it’s only free if your time has no value. From this perspective the OneWebSQL license fee is really not that much. It’s less than what your company pays for your coffee :).
Speaking of the technical issues: OneWebSQL is strictly relational, data-centric approach to interacting with the database. We provide as easy as possible way to access it from Java. Enhanced DTOs do not serve really well as domain objects. That’s why we don’t support inheritance or custom business logic in the generated objects.
Also OneWebSQL fully supports standard JDBC transactions in standalone applications as well as JEE transactions with and without JTA. We do not have any proprietary transaction mechanism. Just pure JDBC and JTA transactions. For details see http://onewebsql.com/docs/1_0_x/transactions-guide/transactions-guide.html
Thanks and good luck!
Tomasz Skutnik
Hi Thomasz,
Thanks a lot for your comments!
> the commercial value of OneWebSQL […]
I understand. Indeed, a fully integrated solution emphasising on the development process as a whole can be an additional asset if you know your target audience will use the tools you suggest. I wasn’t aware that Sybase’s Power Designer had such a strong stand in the market.
> JDBC transactions
OK, that was my misunderstanding, then. I’ll fix this immediately
Cheers and good luck to you too! :-)
Nice blog post. Querydsl has also an abstract query model where expressions are mapped to dialect specific serialization templates, so there is a SQL dialect simulation. Look at the subclasses of SQLTemplates.
Thanks Timo. I will fix that
Sorry for correcting again, but the SQL dialect part is still not quite right. SQL dialect simulation https://github.com/mysema/querydsl/blob/master/querydsl-sql/src/main/java/com/mysema/query/sql/HSQLDBTemplates.java and could you be more clear about the abstraction part? I believe on the query level Querydsl and jOOQ support mostly the same SQL structure.
By abstraction, I mean that there is a common API for several dialects. E.g. jOOQ’s limit(..).offset(..) API will render TOP .. START AT .. in some dialects.
By simulation, I mean that functions / SQL clauses can be entirely simulated. For instance, jOOQ simulates LIMIT .. OFFSET in Oracle using window functions, re-writing the whole SELECT statement. Also, MySQL’s ON DUPLICATE KEY UPDATE clause is simulated using the SQL MERGE statement. I understand now, that QueryDSL does simulation for functions. Does it also do it for SQL clauses?
Yes, at least limit/offset is simulated and there is also simulation of merge clauses.