Book Image

jOOQ Masterclass

By : Anghel Leonard
Book Image

jOOQ Masterclass

By: Anghel Leonard

Overview of this book

jOOQ is an excellent query builder framework that allows you to emulate database-specific SQL statements using a fluent, intuitive, and flexible DSL API. jOOQ is fully capable of handling the most complex SQL in more than 30 different database dialects. jOOQ Masterclass covers jOOQ from beginner to expert level using examples (for MySQL, PostgreSQL, SQL Server, and Oracle) that show you how jOOQ is a mature and complete solution for implementing the persistence layer. You’ll learn how to use jOOQ in Spring Boot apps as a replacement for SpringTemplate and Spring Data JPA. Next, you’ll unleash jOOQ type-safe queries and CRUD operations via jOOQ’s records, converters, bindings, types, mappers, multi-tenancy, logging, and testing. Later, the book shows you how to use jOOQ to exploit powerful SQL features such as UDTs, embeddable types, embedded keys, and more. As you progress, you’ll cover trending topics such as identifiers, batching, lazy loading, pagination, and HTTP long conversations. For implementation purposes, the jOOQ examples explained in this book are written in the Spring Boot context for Maven/Gradle against MySQL, Postgres, SQL Server, and Oracle. By the end of this book, you’ll be a jOOQ power user capable of integrating jOOQ in the most modern and sophisticated apps including enterprise apps, microservices, and so on.
Table of Contents (26 chapters)
1
Part 1: jOOQ as a Query Builder, SQL Executor, and Code Generator
4
Part 2: jOOQ and Queries
11
Part 3: jOOQ and More Queries
16
Part 4: jOOQ and Advanced SQL
22
Part 5: Fine-tuning jOOQ, Logging, and Testing

Handling views in jOOQ

The last section of this chapter is reserved for database views.

A view acts as an actual physical table that can be invoked by name. They fit well for reporting tasks or integration with third-party tools that need a guided query API. By default, the database vendor decides to materialize the results of the view or to rely on other mechanisms to get the same effect. Most vendors (hopefully) don't default to materializing views! Views should behave just like CTE or derived tables and should be transparent to the optimizer. In most cases (in Oracle), we would expect a view to be inlined, even when selected several times, because each time, a different predicate might be pushed down into the view. Actual materialized views are supported only by a few vendors, while the optimizer can decide to materialize the view contents when a view is queried several times. The view's definition is stored in the schema tables so it can be invoked by name wherever...