Hi Venkat, Good thing you asked, although my answer will be biased of course :-) So I invite other members of this user group to join the discussion and to share their views!
*Vision:* * * Many query object models (QOM) have surfaced in the past 10 years, all with a similar ideas and features. jOOQ aims to model SQL as a domain-specific language in Java. In that sense, it is very unique. The things currently being discussed on this user group are very novel and innovative: https://groups.google.com/forum/#!topic/jooq-user/mLcxnwvglf0 My vision is to eventually be able to phrase JSRs that allow for arbitrary external DSL to Java / Scala / Groovy / etc. mappings, making SQL-to-Java a show case of a broader technique. I think that the only really useful Java / SQL contribution to the Java ecosystem is one that really embeds SQL into the Java language. And jOOQ will be the leader of this vision. Having a QOM to back these things is nice. But the QOM itself is not something very innovative. Here are some other QOM implementations (some of which with a DSL-y touch): - http://empire-db.apache.org/empiredb - http://quaere.codehaus.org - http://www.h2database.com/html/jaqu.html - http://ujorm.org - http://www.simpleorm.org - http://xircles.codehaus.org/projects/jequel - http://java.net/projects/squill - http://code.google.com/p/squiggle-sql<https://code.google.com/p/squiggle-sql/> Non-SQL QOMs: - http://docs.oracle.com/javaee/6/api/javax/persistence/criteria/CriteriaQuery.html - http://docs.jboss.org/hibernate/orm/3.3/reference/en/html/querycriteria.html - http://www.day.com/specs/jcr/2.0/6_Query.html - http://docs.mongodb.org/ecosystem/tutorial/getting-started-with-java-driver/ *Feature scope:* * * I have analysed a lot of existing Java / SQL libraries before I started implementing jOOQ, to be sure I won't be reimplementing the wheel and to be sure I will be adding real value. I have found none of them to implement so many SQL function and clause transformations and standardisations as jOOQ does. A couple of examples can be found here on my blog: - http://blog.jooq.org/2013/05/03/sql-query-transformation-fun-predicates-with-row-value-expressions - http://blog.jooq.org/2013/01/07/simulating-the-sql-standard - http://blog.jooq.org/2012/12/26/row-value-expressions-and-the-between-predicate - http://blog.jooq.org/2012/12/24/row-value-expressions-and-the-null-predicate - http://blog.jooq.org/2012/09/21/the-is-distinct-from-predicate - http://blog.jooq.org/2012/07/19/funky-string-function-simulation-in-sqlite The feature scope matches jOOQ's vision. jOOQ is a DSL, i.e. a language. As a language, it models an AST. This AST is transformed by jOOQ itself, depending on your Configuration and Settings (mostly your SQL dialect). For example, the simulation of derived column lists, e.g. SELECT t.a, t.b FROM ( SELECT 1, 2 -- Or any table expression ) t(a, b) -- Derived column list: t(a, b) Which is equivalent to this statement that can do without derived column lists SELECT t.a, t.b FROM ( SELECT null a, null b WHERE 1 = 0 UNION ALL SELECT 1, 2 -- Or any table expression ) t The above is hidden transparently behind the Table.as(String, String...) method: - http://www.jooq.org/javadoc/latest/org/jooq/Table.html#as(java.lang.String, java.lang.String...) Empire-DB's feature scope seems a bit more limited, at least from what I see in their documentation. There are only hints about support for UNIONs, IN predicates, EXISTS predicates, row value expressions, and many more. There is a lot less typesafety in general, and a less fluent API. There is less support for vendor-specific SQL and I think that DML is not supported at all? What about procedures, I couldn't find any references? On the other hand, Empire-DB has some support for DDL, which jOOQ hasn't... *Community and traction:* * * EmpireDB has quite a few committers but rather little traction in general. If you compare its visibility On Stack Overflow: 5 hits (empire db) vs 334 hits (jOOQ) - http://stackoverflow.com/search?q=empiredb - http://stackoverflow.com/search?q=jooq On mailing lists: around 500 (empire db user+dev) vs 3000 (jOOQ user) - http://markmail.org/search/?q=jooq-user - http://markmail.org/search/?q=empiredb On ticketing systems: around 200 (empire db) vs 2600 (jOOQ) - http://issues.apache.org/jira/issues/?jql=project=EMPIREDB - http://github.com/jOOQ/jOOQ/issues *Conclusion:* I might not have really compared the two libraries in particular, but outlined how jOOQ is different and novel compared to *all* pre-existing approaches. In my opinion, you could have picked any other QOM, e.g. Ujorm or one that wasn't on my list, and I would have come to the same conclusion. In fact, I don't see a decisive long-term advantage of choosing Empire-DB over Ujorm. I think that the market is ripe for jOOQ's visions. I think that SQL is a very powerful and expressive language, and it should be possible for a Java developer to write SQL itself directly in Java. Hope this helps :-) 2013/6/30 Venkat Sadasivam <[email protected]> > Just curious to know, what would be the advantage of jOOQ over Apache > Empire-DB <http://empire-db.apache.org/empiredb/stringfree.htm>? > > -- > 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 [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
