Shulou(Shulou.com)06/03 Report--

This article is to share with you about the reasons for the existence of the jOOQ project, the editor thinks it is very practical, so I share it with you to learn. I hope you can get something after reading this article.

What's worth thinking about is why you should (or shouldn't) use JOOQ in a particular project. Specifically, you may be choosing between jOOQ and JPA, or jOOQ and Hibernate, or jOOQ and QueryDSL, or jOOQ and SLICK (for Scala). Here are some guidelines (with a slight bias towards JOOQ, of course):

The reason for the existence of jOOQ-- compared with JPA

Java and SQL have been used together for a long time. SQL is a very "old" but complete technology, and people have a thorough understanding of it. Although some new contemporary languages can be built on top of JVM, the running platform of Java, the Java language is not new. Then, over the years, the Library that handles the interface between SQL and Java is constantly changing, leaving only JPA, a standard that is reluctantly accepted in skepticism, with few other options.

So far, it is rare to really regard SQL as the primary database abstraction framework or library in programming languages. Frameworks, including industry standards JPA, EJB, Hibernate, JDO, Criteria Query, and many others, use JPQL, HQL, JDOQL and various other low-level query languages to minimize the use of SQL, all of which are an attempt to hide SQL itself.

JOOQ to fill this gap.

The reason for the existence of jOOQ-- compared with LINQ

To better integrate query as a concept into the programming language, other platforms use LINQ (along with LINQ-to-SQL), and Scala uses SLICK,Java as well as QueryDSL. Through queries, they can understand queries for arbitrary targets, which can be SQL, XML, Collection, and other heterogeneous data stores (Data Store). JOOQ asserts that this is also going in the wrong direction.

In more advanced query use cases (more advanced than simple CRUD and a small number of multi-table queries), people still want to benefit from the strong expressive power of SQL. The relational nature of SQL makes it very different from what object-oriented languages and incomplete functional programming languages such as C #, Scala, or Java can do.

It is very difficult to formally express and verify the types of expressions for multi-table queries and temporary tables (ad-hoc) they produce. It is even more difficult to support advanced table expressions such as PivotTable (Pivot Table), non-nested cursors (Unnested Cursor), or simply arbitrary projection from derived tables (Projection). How to implement these features in a very strong object-oriented type model is unlikely to be taken into consideration.

In essence, the decision to create an API that looks a lot like SQL or C# or Scala or Java is a decision that is certain or biased towards this or that platform. While it is easy for SLICK to evolve in a way similar to LINQ (or QueryDSL in the Java world), it is difficult to add the SQL feature scope (Feature Scope) that clearly expresses its underlying intentions (for example, how do you model Oracle's partitioned outreach syntax? How to model a grouped set (Grouping Set) in ANSI/ISO SQL:1999? How can scalar quantum query caching be supported? Wait for the question).

JOOQ to fill this gap.

JOOQ is very different.

SQL has never been an abstract language. It is not limited to such a narrow scope as the heavyweight mapper, nor does it hide the beauty and simplicity of relational data. SQL has never been object-oriented. SQL has never been anything other than SQL!

These are the reasons for the existence of the jOOQ project. The editor believes that there are some knowledge points that we may see or use in our daily work. I hope you can learn more from this article. For more details, please follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.