A jOOQ-CodeGenerator to create vertx-ified DAOs and POJOs.
MIT License
Bot releases are hidden (Show)
Published by jklingsporn over 2 years ago
commit()
and rollback()
return a failed Future
/ Completable
instead of throwing an Exception
in case of failurePublished by jklingsporn almost 3 years ago
Published by jklingsporn over 3 years ago
Cursor
or a RowStream<Row>
Flowable<Row>
and Flowable<P>
RowMapper
in reactive QueryExecutors
for convenient usage.Published by jklingsporn over 3 years ago
Published by jklingsporn almost 4 years ago
PgConverter
: previously, PGConverter
was only considered when converting from or into a JsonObject
. Withio.vertx.sqlclient.Row
into your user object. For that reason I'veRowConverter
. For an example check out theCommaSeparatedStringIntoListConverter
.java.util.List<U>
in your POJOs. Checkout the PostgresConfigurationProvider
of how to configure it.CompletableFuture
-API. When this project was started, the io.vertx.core.Future
was in a bad shape.io.vertx.core.Future
-API a first-class choice. In case you really needCompletionStage/CompletableFuture
just call io.vertx.core.Future#toCompletionStage()
toCompletionStage
.Published by jklingsporn almost 4 years ago
The following dependencies have been upgraded:
Note: this will most likely be the last release depending on the vertx 3.x and jooq 3.13.x branches. As vertx will integrate first-class CompletionStage
support and the io.vertx.Future
-API has improved dramatically, we will most likely drop the -completablefuture
modules entirely.
Published by jklingsporn about 4 years ago
@DataObject
annotation to the generated POJOs. This is very handy when youvertx-codegen
-module this feature is disabled by default. This is how you enable itVertxGeneratorBuilder.init().withClassicAPI().withPostgresReactiveDriver().build(new BuildOptions().withBuildFlags(EnumSet.of(BuildOptions.BuildFlag.GENERATE_DATA_OBJECT_ANNOTATION)))
to/fromJson
-conversion of LocalDateTime
, OffsetDateTime
, ZonedDateTime
, LocalTime
and LocalDate
Published by jklingsporn over 4 years ago
Published by jklingsporn over 4 years ago
PgConverter
for the reactive modules. This gives users finally the opportunity to use custom POJOs instead of JsonObjects
. The generators are also properly used in the fromJson
and toJson
-methods.BuildOptions
when creating a code generator using VertxGeneratorBuilder
. Currently one flag can be set which determines whether to use singletons (default) for converters or instantiate them every time. When set to SINGLETON
-mode, this will create a class with references to all Converters
and Bindings
that are used.findManyBy
-methods now take Collection
as argumentQueryResult
https://github.com/jklingsporn/vertx-jooq/milestone/18?closed=1
Published by jklingsporn over 4 years ago
Bugfix release to solve compatibility with Java 11.
Issues:
Published by jklingsporn over 4 years ago
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
Published by jklingsporn over 5 years ago
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
});
Published by jklingsporn almost 6 years ago
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 theClassicQueryExecutor
,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 distinguishVertxGenerator
of your choice.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>>
.Configuration
object in order to execute random jOOQ SQL.JDBCQueryExecutor.execute
was renamed to JDBCQueryExecutor.executeAny
.vertx-jooq-classic-async
).GeneratorStrategies
all have to extend now from VertxGeneratorStrategy
.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
Published by jklingsporn over 6 years ago
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 theClassicQueryExecutor
,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 distinguishVertxGenerator
of your choice.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>>
.Configuration
object in order to execute random jOOQ SQL.JDBCQueryExecutor.execute
was renamed to JDBCQueryExecutor.executeAny
.vertx-jooq-classic-async
).GeneratorStrategies
all have to extend now from VertxGeneratorStrategy
.QueryExecutors
you'll have to change the method calls to it as described above.Related issues:
Published by jklingsporn over 6 years ago
Another community release! Thanks to @quen2404 all DAOs can now fetch POJOs ordered.
Published by jklingsporn over 6 years ago
Kudos go out to @quen2404 and @gurpreet for providing the PRs!
Published by jklingsporn over 6 years ago
Some bugs fixed affecting the async driver:
Published by jklingsporn over 6 years ago
vertx-jooq
both includes the JDBCvertx-jooq-async
). ThisHelloWorld
applicationFutures
instead of accepting aHandler
to deal with the result.vertx-jooq-future
becomes vertx-jooq-completablefuture
: that was more or less a consequence of the decision to let theFutures
now.SELECT
with find
, followed by One
ifMany
if it is capable to return many values, followed by a condition to define how the value isbyId
. 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.Vertx.executeBlocking
block to get the async variantinsertReturningPrimary
), update and delete-methods now contain information about the number of affected rows.Published by jklingsporn almost 7 years ago