This launch tackles two lengthy standing and complicated function requests that customers
have requested us to supply for a very long time: a public API for manipulating jOOQ’s
question object mannequin (QOM), and spatial help.
New Question Object Mannequin (QOM)
Each jOOQ question is modeled as an expression tree constructed by way of our intuitive
DSL. For some use-cases there exist historic mannequin API variations (e.g.SelectQuery), however these fashions aren’t readable or transformable. We’re now
beginning to provide most of our expression tree mannequin as a public API for customers to
devour and manipulate. Each expression tree factor has a corresponding kind
in org.jooq.impl.QOM. Each kind gives entry to its elements utilizing "$"
prefixed methodology names, e.g.:
// Create an expression utilizing the DSL API:
Discipline area = substring(BOOK.TITLE, 2, 4);
// Entry the expression's internals utilizing the mannequin API
if (area instanceof QOM.Substring substring) {
Discipline string = substring.$string();
Discipline startingPosition = substring.$startingPosition();
Discipline size = substring.$size();
}
The brand new API is experimental and may change within the subsequent minor launch.
Licensed energy customers will get auxiliary APIs to traverse and remodel the
expression tree, e.g. traversal:
// Comprises 7 question components
lengthy count2 = BOOK.ID.eq(1).or(BOOK.ID.eq(2))
.$traverse(Traversers.accumulating(Collectors.counting());
Or substitute:
// Comprises redundant operators
Situation c = not(not(BOOK.ID.eq(1)));
System.out.println(c.$substitute(q ->
q instanceof QOM.Not n1 && n1.$arg1() instanceof QOM.Not n2
? n2.$arg1()
: q
));
The above prints the next, having eliminated the redundant NOT operators:
"BOOK"."ID" = 1
This new API may be very highly effective for much more subtle dynamic SQL use-cases,
reminiscent of:
- Optimising SQL expressions because the above NOT NOT instance
- Row stage safety
- Gentle deletion
- Shared schema multi tenancy
- Audit column help
- And far more (keep tuned for future blogs and out-of-the-box transformations)
For more information, see:
Spatial help
A protracted awaited function that begins delivery to our commercially licensed
prospects is spatial help. Many dialects help the ISO/IEC 13249-3:2016 SQL
commonplace extension, and at last, so can we.
jOOQ introduces new auxiliary knowledge varieties for GEOMETRY and GEOGRAPHY knowledge to make use of
as standardised bind variables, containing WKB or WKT knowledge, in addition to a
number of out of the field features and predicates.
Future variations will add extra help for different features and dialects.
New dialect and variations
One other new formally supported SQL dialect has been added to all jOOQ editions
together with the jOOQ Open Supply Version: YugabyteDB. This was a sponsored
integration, thanks very a lot Yugabyte!
Different dialects have upgraded variations, which means:
- We help this model in all editions now
- The jOOQ Open Supply Version now requires this model if relevant
The variations are:
- Firebird 4.0
- H2 2.0.202
- MariaDB 10.6
- PostgreSQL 14
- Oracle 21c
Computed and readonly columns together with ROWID
Loads of dialects help computed columns (“generated” columns), and we now
help these as properly in jOOQ. For many use-cases, this doesn’t have an effect on jOOQ
utilization, however particularly when writing CRUD code, the brand new readonly column function
could be very useful to keep away from having to exclude computed columns manually from
the CRUD operation.
This additionally features a new, improved ROWID help, the place customers can select to work
with an artificial ROWID column as an alternative of the first key, when performing CRUD
operations.
All of those options can be found within the business jOOQ editions.
Jakarta EE
We’ve moved on from Java EE to Jakarta EE dependencies. This modification is
at present backwards incompatible as a result of:
- It vastly facilitates sustaining the associated code
- It prevents tons of consumer issues ensuing from having each dependencies
- We’re not really integrating tightly with Java EE / Jakarta EE
The next Jakarta EE modules are affected:
- JAXB, which we’re utilizing to load our configuration objects.
- Validation, whose annotations could be generated by the code generator.
- JPA, which is utilized by the DefaultRecordMapper and the JPADatabase
If this breaking change causes points, please get in contact at
https://github.com/jOOQ/jOOQ/points/9641
Numerous enhancements
As with each minor launch, a variety of smaller enhancements have been
carried out. Some highlights embrace:
- PostgreSQL procedures are actually supported in code technology and at runtime.
- SQLite JSON help has been added, which incorporates the MULTISET emulation!
- Loads of MULTISET / ROW enhancements have been carried out
- R2DBC 0.9 has been launched, and we’ve upgraded our dependency
- The Java 17 distribution now requires Java 17 as an alternative of Java 16
- Pre jOOQ 3.6 deprecations have been eliminated
