Class VirtDataComposer

java.lang.Object
io.nosqlbench.virtdata.core.bindings.VirtDataComposer
public class VirtDataComposer extends Object

Synopsis

This library implements the ability to compose a lambda function from a sequence of other functions. The resulting lambda will use the specialized primitive function interfaces, such as LongUnaryOperator, LongFunction, etc. Where there are two functions which do not have matching input and output types, the most obvious conversion is made. This means that while you are able to compose a LongUnaryOperator with a LongUnaryOperator for maximum efficiency, you can also compose LongUnaryOperator with an IntFunction, and a best effort attempt will be made to do a reasonable conversion in between.

Limitations

Due to type erasure, it is not possible to know the generic type parameters for non-primitive functional types. These include IntFunction<?>, LongFunction<?>, and in the worst case, Function<?,?>. For these types, annotations are provided to better inform the runtime lambda compositor.

Multiple Paths

The library allows for there to be multiple functions which match the spec, possibly because multiple functions have the same name, but exist in different libraries or in different packages within the same library. This means that the composer library must find a connecting path between the functions that can match at each stage, disregarding all but one.

Path Finding

The rule for finding the best path among the available functions is as follows, at each pairing between adjacent stages of functions:

  1. The co-compatible output and input types between the functions are mapped. Functions sharing the co-compatible types are kept in the list. Functions not sharing them are removed.
  2. As long as functions can be removed in this way, the process iterates through the chain, starting again at the front of the list.
  3. When no functions can be removed due to lack of co-compatible types, each stage is selected according to type preferences as represented in ValueType
  4. If the next (outer) function does not have a compatible input type, move it down on the list. If, after this step, there are functions which do have matching signatures, all others are removed.