5.0.1

Bugfix release to solve compatibility with Java 11.

Issues:

• #67

5.0.0

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

4.1.0

• 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.

4.0.0

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

4.0.0-BETA

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

3.1.0

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

3.0.2

• 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!

3.0.1

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

3.0.0

• 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.

2.4.1

• 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.