A jOOQ-CodeGenerator to create vertx-ified DAOs and POJOs.
Bugfix release to solve compatibility with Java 11.
Issues:
This release's focus was on upgrading the vertx-dependency to 3.8.x. It took a bit longer than expected to apply the required changes because of two things:
Promise
https://github.com/jklingsporn/vertx-jooq/milestone/16?closed=1
QueryExecutor
. There are two ways to work with transactions:
Future<Void> transactionWork = dao.queryExecutor()
.beginTransaction()
.compose(
transactionQE -> {
//only work on the "transactional" QueryExecutor returned by the beginTransaction() method
Future<Integer> insert1 = transactionQE.execute(dslContext -> dslContext.insertInto() ....;
Future<Integer> insert2 = transactionQE.execute(dslContext -> dslContext.insertInto() ....;
return CompositeFuture
.all(insert1,insert2)
.compose(v->transactionQE.commit() /*or .rollback()*/); //don't forget to commit your transaction
});
Future<Void> transactionWork = dao.queryExecutor()
.transaction(
transactionQE -> {
//only work on the "transactional" QueryExecutor returned by the transaction() method
Future<Integer> insert1 = transactionQE.execute(dslContext -> dslContext.insertInto() ....;
Future<Integer> insert2 = transactionQE.execute(dslContext -> dslContext.insertInto() ....;
return CompositeFuture.all(insert1,insert2);
//or return some result
});
vertx-jooq
adds support for this winning, high performance postgres driver.DAO#insertReturning
for the async postgres driver.UnifiedQueryExecutor
interface that allows the execution of arbitrary jOOQ-SQL against an API with the
same return value for all drivers! Currently there are three interfaces you can use: ClassicQueryExecutor
,
CompletableFutureQueryExecutor
and RXQueryExecutor
. The following is possible now://first, you decide to use the classic API using JDBC
ClassicQueryExecutor queryExecutor = new JDBCClassicGenericQueryExecutor(configuration,vertx);
Future<QueryResult> queryResult = queryExecutor.query(dslContext ->
dslContext
.selectFrom(Tables.SOMETHING)
.where(Tables.SOMETHING.SOMEID.eq(something.getSomeid()))
);
//fetching values using new QueryResult-API
queryResult.map(res -> {
Integer someId = res.get(Tables.SOMETHING.SOMEID);
return someId;
});
...
//now some time in the future you decide to use the reactive driver instead
ClassicQueryExecutor queryExecutor = new ReactiveClassicGenericQueryExecutor(configuration,pgClient);
//the return value for the query didn't change!
Future<QueryResult> queryResult = queryExecutor.query(dslContext ->
dslContext
.selectFrom(Tables.SOMETHING)
.where(Tables.SOMETHING.SOMEID.eq(something.getSomeid()))
);
queryResult.map(res -> {
Integer someId = res.get(Tables.SOMETHING.SOMEID);
//hooray same API
return someId;
});
QueryExecutor
from every DAO by calling DAO.queryExecutor()
.GeneratorStrategies
to generate DAOs: it was a misconception to use GeneratorStrategies
to distinguish
between the APIs, drivers and injection-support. Instead, there is now a Builder-API to create the VertxGenerator
of your choice.
This comes in handy if you configure your jOOQ code generator programmatically. Example:VertxGenerator vertxGenerator = VertxGeneratorBuilder
.init()
.withClassicAPI()
.withAsyncDriver()
.withGuice(true)
.build();
org.jooq.Configuration
, instead it is now located in the QueryExecutor
.QueryExecutor
API changed in a way, that all methods no longer accept instances of org.jooq.Query
but Function<DSLContext, ? extends ResultQuery<R>>
.
It is no longer necessary to keep a Configuration
object in order to execute random jOOQ SQL.JDBCQueryExecutor.execute
was renamed to JDBCQueryExecutor.executeAny
.vertx-jooq-classic-async
).
If you've used own GeneratorStrategies
all have to extend now from VertxGeneratorStrategy
.
Then, update the dependencies to the code-generator and generate the code. Now you should update the vertx-jooq-YOUR_API-YOUR_DRIVER
dependency. In case you've been using QueryExecutors
you'll have to change the method calls to it as described above.Related issues: https://github.com/jklingsporn/vertx-jooq/milestone/11?closed=1
vertx-jooq
adds support for this winning, high performance postgres driver.DAO#insertReturning
for the async postgres driver.UnifiedQueryExecutor
interface that allows the execution of arbitrary jOOQ-SQL against an API with the
same return value for all drivers! Currently there are three interfaces you can use: ClassicQueryExecutor
,
CompletableFutureQueryExecutor
and RXQueryExecutor
. The following is possible now://first, you decide to use the classic API using JDBC
ClassicQueryExecutor queryExecutor = new JDBCClassicGenericQueryExecutor(configuration,vertx);
Future<QueryResult> queryResult = queryExecutor.query(dslContext ->
dslContext
.selectFrom(Tables.SOMETHING)
.where(Tables.SOMETHING.SOMEID.eq(something.getSomeid()))
);
//fetching values using new QueryResult-API
queryResult.map(res -> {
Integer someId = res.get(Tables.SOMETHING.SOMEID);
return someId;
});
...
//now some time in the future you decide to use the reactive driver instead
ClassicQueryExecutor queryExecutor = new ReactiveClassicGenericQueryExecutor(configuration,pgClient);
//the return value for the query didn't change!
Future<QueryResult> queryResult = queryExecutor.query(dslContext ->
dslContext
.selectFrom(Tables.SOMETHING)
.where(Tables.SOMETHING.SOMEID.eq(something.getSomeid()))
);
queryResult.map(res -> {
Integer someId = res.get(Tables.SOMETHING.SOMEID);
//hooray same API
return someId;
});
QueryExecutor
from every DAO by calling DAO.queryExecutor()
.GeneratorStrategies
to generate DAOs: it was a misconception to use GeneratorStrategies
to distinguish
between the APIs, drivers and injection-support. Instead, there is now a Builder-API to create the VertxGenerator
of your choice.
This comes in handy if you configure your jOOQ code generator programmatically. Example:VertxGenerator vertxGenerator = VertxGeneratorBuilder
.init()
.withClassicAPI()
.withAsyncDriver()
.withGuice(true)
.build();
org.jooq.Configuration
, instead it is now located in the QueryExecutor
.QueryExecutor
API changed in a way, that all methods no longer accept instances of org.jooq.Query
but Function<DSLContext, ? extends ResultQuery<R>>
.
It is no longer necessary to keep a Configuration
object in order to execute random jOOQ SQL.JDBCQueryExecutor.execute
was renamed to JDBCQueryExecutor.executeAny
.vertx-jooq-classic-async
).
If you've used own GeneratorStrategies
all have to extend now from VertxGeneratorStrategy
.
Then, update the dependencies to the code-generator and generate the code. Now you should update the vertx-jooq-YOUR_API-YOUR_DRIVER
dependency. In case you've been using QueryExecutors
you'll have to change the method calls to it as described above.Related issues:
Another community release! Thanks to @quen2404 all DAOs can now fetch POJOs ordered.
Kudos go out to @quen2404 and @gurpreet for providing the PRs!
Some bugs fixed affecting the async driver:
vertx-jooq
both includes the JDBC
and the async variant (formerly known as vertx-jooq-async
). This
avoids duplicate code and thus provides better stability.HelloWorld
application
hates callback-APIs. That is why I decided to let the classic-module now return Vertx Futures
instead of accepting a
Handler
to deal with the result.vertx-jooq-future
becomes vertx-jooq-completablefuture
: that was more or less a consequence of the decision to let the
classic API return Futures
now.SELECT
with find
, followed by One
if
it returns one value, or Many
if it is capable to return many values, followed by a condition to define how the value is
obtained, eg byId
. If you are upgrading from a previous version, you will have to run some search and replace sessions in your favorite IDE.QueryExecutors
though.VertxDAO
extended from jOOQ's DAOImpl
class.
This made it easy to just wrap the blocking variant of a CRUD-operation in a Vertx.executeBlocking
block to get the async variant
of it. The downside however was that the blocking CRUD-operations were still visible in the DAO-API and it was up to the user
to call the correct (async) method. The blocking variants have been removed from the API - all calls are now asynchronous.insertReturningPrimary
), update and delete-methods now contain information about the number of affected rows.
The result is a cleaner, thinner API.