OneWebSQL™: Another competitor in the SQL schema generation “business”

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:


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


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


Feature jOOQ QueryDSL OneWebSQL™
Source code generation [1] yes yes yes
Active Records [2] yes partially
(through JPA)
(through generated DAOs)
Procedure support [3] yes no partially
(some JDBC abstraction)
UDT support [3] yes no no
DSL [4] yes
(formal BNF notation)
(chained methods)
(chained methods)
DML support yes yes yes
DDL support no no no
Supported RDBMS 13 9
(or more, using JPA)
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
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.


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’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’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™’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

13 thoughts on “OneWebSQL™: Another competitor in the SQL schema generation “business”

  1. 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.

  2. 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…

    1. > I was going to write an article about joist


      > 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.

      1. > 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!

  3. 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

    Thanks and good luck!

    Tomasz Skutnik

    1. 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! :-)

  4. 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.

    1. 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?

Leave a Reply to lukaseder Cancel reply