[ad_1]
This launch tackles two lengthy standing and sophisticated characteristic 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 supply most of our expression tree mannequin as a public API for customers to
devour and manipulate. Each expression tree ingredient has a corresponding sort
in org.jooq.impl.QOM. Each sort gives entry to its parts utilizing "$"
prefixed methodology names, e.g.:
// Create an expression utilizing the DSL API:
Subject discipline = substring(BOOK.TITLE, 2, 4);
// Entry the expression's internals utilizing the mannequin API
if (discipline instanceof QOM.Substring substring) {
Subject string = substring.$string();
Subject startingPosition = substring.$startingPosition();
Subject 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:
// Incorporates 7 question elements
lengthy count2 = BOOK.ID.eq(1).or(BOOK.ID.eq(2))
.$traverse(Traversers.amassing(Collectors.counting());
Or alternative:
// Incorporates redundant operators
Situation c = not(not(BOOK.ID.eq(1)));
System.out.println(c.$exchange(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,
resembling:
- Optimising SQL expressions because the above NOT NOT instance
- Row stage safety
- Smooth 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 characteristic that begins delivery to our commercially licensed
clients is spatial help. Many dialects help the ISO/IEC 13249-3:2016 SQL
commonplace extension, and eventually, so will we.
jOOQ introduces new auxiliary knowledge sorts 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, that 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
A variety 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 characteristic
will 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 industrial jOOQ editions.
Jakarta EE
We’ve moved on from Java EE to Jakarta EE dependencies. This alteration is
at the moment backwards incompatible as a result of:
- It enormously facilitates sustaining the associated code
- It prevents tons of person issues ensuing from having each dependencies
- We’re not truly 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 will 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
Varied enhancements
As with each minor launch, numerous smaller enhancements have been
applied. Some highlights embrace:
- PostgreSQL procedures are actually supported in code era and at runtime.
- SQLite JSON help has been added, which incorporates the MULTISET emulation!
- A variety of MULTISET / ROW enhancements have been applied
- 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
[ad_2]
