Assembler v0.3.1

The biggest change in this release is the addition of reactive-assembler-core library, which is a complete rewrite of the original assembler-core library to natively support reactive programming. It is strongly recommended to use reactive-assembler-core from now on. The reactive-assembler-kotlin-extension lib was also created to help make reactive-assembler-core more usable in a Kotlin idiomatic way

Assembler v0.2.0

This release introduces a big rework of the library internals with a breaking spi change for the various implementations of AssemblerAdapter, enough for a semantic version bump to 0.2.0, more specifically:

• Implementations of AssemblerAdapter are now responsible to trigger the retrieval of top level entities i.e. responsible for the initial call/query from which we extract the correlation ids (i.e. primary/foreign keys)
  • This behavior aligns with the semantics of cold reactive Publisher which should only be triggered upon a subscription from a Subscriber i.e. the whole reactive pipeline is now lazy executed.
• Specifically for the Eclipse MicroProfile Reactive Streams Operators implementation through the PublisherBuilderAdapter:
  • Since there is currently no equivalent to a Project Reactor Flux.zip or RxJava Flowable.zip operator, we need to implement a zip like operator with CompletableFuture which are eagerly triggered, so a new delegate implementation of PublisherBuilder was introduced (LazyPublisherAdapter) to wrap any existing PublisherBuilder to trigger the construction and execution of a reactive stream pipeline only upon an invocation of a terminal operation derived from a PublisherBuilder (e.g. calling run() on a CompletionRunner or when a Subscriber subscribes to a Publisher)

Assembler v0.1.8

This release introduces support for Eclipse MicroProfile Reactive Streams Operators through the PublisherBuilderAdapter, see https://github.com/pellse/assembler#eclipse-microprofile-reactive-stream-operators for a usage example.

Assembler v0.1.7

This release includes the following:

• The ability to customize the Map implementation internally used for indexing each subqueries
  • See https://github.com/pellse/assembler#pluggable-map-implementations
• Returns empty results instead of throwing NullPointerException for null top level entities
• Updated Project Reactor dependency to version 3.3.0.RELEASE
• Updated RxJava dependency to version 3.0.0-RC3
• Updated Akka Stream dependency to version 2.5.25

Assembler v0.1.5

This release introduced a non-breaking change to the api, Assembler.assemble() now accept an Iterable instead of a Collection to model the top level entities to be aggregated with results from sub-queries.

Assembler v0.1.4

This release contains small refactoring with one change visible to the user, in QueryUtils.queryOneToOne (and indirectly also in MapUtils.oneToOne) methods, passing a null defaultResultProvider parameter is now converted into a function that returns null

Assembler v0.1.3

This release only contains a small api change, the Assembler static inner interface was moved out AssemblerBuilder and is now a top level interface

Assembler v0.1.2

This release brings the capability to reuse an Assembler created with the fluent builder api while keeping type inference, see issue #9

Assembler v0.1.1

Minor release with the following changes:

• Updated RxJava to version 2.2.0
• Updated Akka Stream to version 2.5.14
• New MapperUtils.cached(Mapper<ID, R, EX> delegate) method to wrap assembler rules e.g. oneToOne(), oneToMany()) and allow caching of Mapper invocations

Assembler v0.1.0

This release fixes the following:

1. More intuitive and consistent naming for the Assembler DSL e.g.:

Flux<Transaction> transactionFlux = assemblerOf(Transaction.class)
    .fromSourceSupplier(this::getCustomers, Customer::getCustomerId)
    .withAssemblerRules(
        oneToOne(this::getBillingInfoForCustomers, BillingInfo::getCustomerId),
        oneToManyAsList(this::getAllOrdersForCustomers, OrderItem::getCustomerId),
        Transaction::new)
    .assembleUsing(fluxAdapter(elastic()))

2. Avoid unnecessary creation of Supplier when we already have a materialized source collection to work with