vertx-jooq

A jOOQ-CodeGenerator to create vertx-ified DAOs and POJOs! Perform all CRUD-operations asynchronously and convert your POJOs from/into a io.vertx.core.json.JsonObject using the API and driver of your choice.

release 5.2.0

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

different needs, different apis

Before you start generating code using vertx-jooq, you have to answer these questions:

What API do you want to use? There are three options:
- a io.vertx.core.Future-based API. This is vertx-jooq-classic.
- a rxjava2 based API. This is vertx-jooq-rx.
- an API that returns a vertx-ified implementation of java.util.concurrent.CompletableFuture for all async DAO operations. This is vertx-jooq-completablefuture.
How do you want to communicate with the database? There are two options:
- Using good old JDBC, check for the modules with -jdbc suffix.
- Using this asynchronous database driver, check for -async modules.
- Using this reactive postgres database driver, check for -reactive modules.
Advanced configuration:
- Support for Guice dependency injection
- Generation of io.vertx.codegen.annotations.@DataObject-annotations for your POJOs

When you made your choice, you can start to configure the code-generator. This can be either done programmatically or using a maven- / gradle-plugin (recommended way). Please check the documentation in the module of the API of your choice how to set it up:

example

Once the generator is set up, it will create DAOs like in the code snippet below (classic-API, JDBC, no dependency injection):

//Setup your jOOQ configuration
Configuration configuration = ...

//setup Vertx
Vertx vertx = Vertx.vertx();

//instantiate a DAO (which is generated for you)
SomethingDao dao = new SomethingDao(configuration,vertx);

//fetch something with ID 123...
dao.findOneById(123)
    .onComplete(res->{
    		if(res.succeeded()){
        		vertx.eventBus().send("sendSomething", res.result().toJson())
    		}else{
    				System.err.println("Something failed badly: "+res.cause().getMessage());
    		}
    });

//maybe consume it in another verticle
vertx.eventBus().<JsonObject>consumer("sendSomething", jsonEvent->{
    JsonObject message = jsonEvent.body();
    //Convert it back into a POJO...
    Something something = new Something(message);
    //... change some values
    something.setSomeregularnumber(456);
    //... and update it into the DB
    Future<Integer> updatedFuture = dao.update(something);
});

//or do you prefer writing your own type-safe SQL? Use the QueryExecutor from the DAO...
ClassicQueryExecutor queryExecutor = dao.queryExecutor();
//... or create a new one when there is no DAO around :)
queryExecutor = new JDBCClassicGenericQueryExecutor(configuration,vertx);
Future<Integer> updatedCustom = queryExecutor.execute(dslContext ->
				dslContext
				.update(Tables.SOMETHING)
				.set(Tables.SOMETHING.SOMEREGULARNUMBER,456)
				.where(Tables.SOMETHING.SOMEID.eq(something.getSomeid()))
				.execute()
);

//check for completion
updatedCustom.onComplete(res->{
		if(res.succeeded()){
				System.out.println("Rows updated: "+res.result());
		}else{
				System.err.println("Something failed badly: "+res.cause().getMessage());
		}
});

handling custom datatypes

The generator will omit datatypes that it does not know, e.g. java.sql.Timestamp. To fix this, you can subclass the generator, handle these types and generate the code using your generator. See the handleCustomTypeFromJson and handleCustomTypeToJson methods in the AbstractVertxGenerator or checkout the CustomVertxGenerator from the tests.

disclaimer

This library comes without any warranty - just take it or leave it. Also, the author is neither connected to the company behind vertx nor the one behind jOOQ.

wangdefeng / vertx-jooq