• Fix Use enum literal instead of toString for datatype conversion #209
• Update to jooq 3.17.3
• Update to vertx 4.3.3
• Update mutiny dependencies
• Update rx dependencies

• Add modules for mutiny-API!
• Fix Reactive QueryExecutor transaction rollback fails to close connection.
• Make commit() and rollback() return a failed Future / Completable instead of throwing an Exception in case of failure
  for the reactive QueryExecutors.

• Added rxjava3 support via dedicated vertx-jooq-rx3-reactive module.
• Added BigDecimal support.
• Breaking change: Minimum required Java version changed from 8 to 11 (required by latest jOOQ version).
• Bumped Vert.x version to 4.2.3
• Bumped jOOQ version to 3.15.5

• Added stream support for the reactive drivers. This long overdue
  feature allows you to process large chunks of data without running out of memory. The available methods depend on the chosen API:
  • Classic
    • choose between the usage of a Cursor or a RowStream<Row>
    • Cursor example
    • RowStream example
  • RX
    • choose between Flowable<Row> and Flowable<P>
    • Flowable example
• Expose the used RowMapper in reactive QueryExecutors for convenient usage.

• Add support for jooq 3.14 #166

Vertx 4 Support

• Upgrade vertx to 4.0.0. A big shout out to vertx-jooq user doctorpangloss for the
  groundwork.
• Enhanced PgConverter: previously, PGConverter was only considered when converting from or into a JsonObject. With
  the new release you can now convert anything from a io.vertx.sqlclient.Row into your user object. For that reason I've
  introduced the new RowConverter. For an example check out the
  CommaSeparatedStringIntoListConverter.
• Added support of user-types like java.util.List<U> in your POJOs. Checkout the PostgresConfigurationProvider of how to configure it.
• Removal of the async driver. There is actually no reason to use this driver over the reactive driver from vertx. It
  just adds confusion for initial users and worsens maintainability.
• Removal of the CompletableFuture-API. When this project was started, the io.vertx.core.Future was in a bad shape.
  Many methods for composition and error handling were missing and made it hard to actually use. In the past couple
  of months this has been fixed - making the io.vertx.core.Future-API a first-class choice. In case you really need
  the interoperability with CompletionStage/CompletableFuture just call io.vertx.core.Future#toCompletionStage() to
  convert it into, or the static method Future.createFromCompletionStage to convert from a CompletionStage.

The following dependencies have been upgraded:

• upgrade junit to 4.13.1
• upgrade vertx to 3.9.4
• upgrade jooq to 3.13.5
  The following bug has been fixed
• #159 fix an issue for windows users and the generated package names

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.

• Add @DataObject for generated POJOs
  • This nice enhancement allows you to add the @DataObject annotation to the generated POJOs. This is very handy when you
    are working with ServiceProxies etc.
  • Due to the dependency to the vertx-codegen-module this feature is disabled by default. This is how you enable it
    for the classic reactive generator: VertxGeneratorBuilder.init().withClassicAPI().withPostgresReactiveDriver().build(new BuildOptions().withBuildFlags(EnumSet.of(BuildOptions.BuildFlag.GENERATE_DATA_OBJECT_ANNOTATION)))
• Add limit to generated findMany-methods
  • Conveniently find many POJOs limited by your choice
• Default conversion of java.util.time types
  • Finally handles the to/fromJson-conversion of LocalDateTime, OffsetDateTime, ZonedDateTime, LocalTime and LocalDate
• Support postgres bytea type in the reactive driver
• Upgrade to vert.x 3.9.2
• Upgrade to jOOQ 3.13.3
• Link to all resolved issues

• fix Generation fails when module's path contains .
• fix dao.insertReturningPrimary fails with java.util.NoSuchElementException
• fix JSONB to JsonObject Convertor Failure when using postgres reactive classic
• vertx 3.9.1 upgrade
• jooq 3.13.2 upgrade

Noteworthy additions / changes

• Introduction of 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.
• New 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.
• Upgrade to jOOQ 3.13.1
• BREAKING findManyBy-methods now take Collection as argument
• Stream over QueryResult

Resolved issues

https://github.com/jklingsporn/vertx-jooq/milestone/18?closed=1

Bugfix release to solve compatibility with Java 11.

Issues:

• https://github.com/jklingsporn/vertx-jooq/issues/67

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:

• introduction of Promise
• and reactive-driver dependency changes
  Especially the latter took some time, but here we are. Thanks again for all the activity on this project and your contributions ❤️

Resolved issues

https://github.com/jklingsporn/vertx-jooq/milestone/16?closed=1

• The main addition in this release is transaction support for reactive modules.
  Transaction are now added onto the reactive variants of the QueryExecutor. There are two ways to work with transactions:
  1. The manual mode involves starting and manually committing or rolling back the transaction.

     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
     		});
     

  2. The "convenient mode"" is the best choice for most situations. It allows you to work in a transactional context that
     automatically commits your work when you are done. You can also return a value from your transactional work.

     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
     		});
     

• Another important change was the switch to a maintained fork of the async driver
  which was introduced in vertx 3.6.3 and will be the default implementation in the next releases.
  The API stays the same but the driver is written in Kotlin instead of Scala. Checkout the migration guide
  for more details.
• Click here for a complete list of all features and bugfixes.

Fast, faster, reactive

• Starting from version 4.x, vertx-jooq adds support for this winning, high performance postgres driver.
• Finally added support for DAO#insertReturning for the async postgres driver.
• A new 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;
});

• In addition you can now obtain the QueryExecutor from every DAO by calling DAO.queryExecutor().
• Move away from 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();

• Breaking changes:
  • DAOs are no longer aware of 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.
  • Upgrade from 3.x: first, change the generator- and strategy name in your code generator configuration.
    Use the names as described in the module's documentation of the API and driver of your choice (e.g. 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

Fast, faster, reactive.

• Starting from this version on, vertx-jooq adds support for this winning, high performance postgres driver.
• Finally added support for DAO#insertReturning for the async postgres driver.
• A new 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;
});

• In addition you can now obtain the QueryExecutor from every DAO by calling DAO.queryExecutor().
• Move away from 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();

• Breaking changes:
  • DAOs are no longer aware of 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.
  • Upgrade from 3.x: first, change the generator- and strategy name in your code generator configuration.
    Use the names as described in the module's documentation of the API and driver of your choice (e.g. 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:

• Overload insert-methods in VertxDAO to allow/set onDuplicateKeyIgnore #46
• QueryExecutors of one API should share same method signature #45
• QueryExecutor API changes #44
• Move away from GeneratorStrategies to generate DAOs #36
• Allow insertReturning for Postgres in async mode #35
• Add pg-reactive-client as optional driver #34

Another community release! Thanks to @quen2404 all DAOs can now fetch POJOs ordered.

• Allow sorting in findManyByCondition method #43
• upgrade jOOQ-dependency to 3.10.6

• fixed compilation fails when interfaces generation is set to false #37
• merged PR Add OffsetDateTime and Instant converters #38
• merged PR Fix number of parameters when using condition contains #40

Kudos go out to @quen2404 and @gurpreet for providing the PRs!

Some bugs fixed affecting the async driver:

• fixed java.time.LocalDateTime in JsonObject during update #31
• fixed Enum type cannot be used in async driver #32
• fixed Enums cannot have default values and non-nullability #33

• Starting from this version on, 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.
• Say good bye callback-API: everybody who has written code that is more complex than a simple 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.
• Consistent naming: I decided to prefix any DAO-method that is based on a 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.
• DAOs are no longer capable of executing arbitrary SQL. There were two main drivers for this decision: 1. joining the JDBC
  and the async API did not allow it. 2. DAOs are bound to a POJO and should only operate on the POJO's type. With the option to execute any
  SQL one could easily join on POJOs of other types and thus break boundaries. You can still execute type-safe SQL asynchronously
  using one of the QueryExecutors though.
• Never again call blocking DAO-methods by accident: in previous vertx-jooq versions every 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.
• All insert (except insertReturningPrimary), update and delete-methods now contain information about the number of affected rows.
  The result is a cleaner, thinner API.
• Guice finally available for all async APIs.

• Bugfix
  • Remove dependencies to rxjava1 #26
    Although it was announced otherwise, vertx-jooq-rx version 2.4.0 still had dependencies to rxjava1. This has finally been fixed.