Package org.apache.drill.exec.physical.resultSet.model.hyper

Class HyperReaderBuilder

java.lang.Object
org.apache.drill.exec.physical.resultSet.model.ReaderBuilder
org.apache.drill.exec.physical.resultSet.model.hyper.HyperReaderBuilder
public class HyperReaderBuilder extends ReaderBuilder
Base reader builder for a hyper-batch. The semantics of hyper-batches are a bit rough. When a single batch, we can walk the vector tree to get the information we need. But, hyper vector wrappers don't provide that same information, so we can't just walk them. Further, the code that builds hyper-batches appears perfectly happy to accept batches with differing schemas, something that will cause the readers to blow up because they must commit to a particular kind of reader for each vector.

The solution is to build the readers in two passes. The first builds a metadata model for each batch and merges those models. (This version requires strict identity in schemas; a fancier solution could handle, say, the addition of map members in one batch vs. another or the addition of union/list members across batches.)

The metadata (by design) has the information we need, so in the second pass we walk the metadata hierarchy and build up readers from that, creating vector accessors as we go to provide a runtime path from the root vectors (selected by the SV4) to the inner vectors (which are not represented as hypervectors.)

The hypervector wrapper mechanism provides a crude way to handle inner vectors, but it is awkward, and does not lend itself to the kind of caching we'd like for performance, so we use our own accessors for inner vectors. The outermost hyper vector accessors wrap a hyper vector wrapper. Inner accessors directly navigate at the vector level (from a vector provided by the outer vector accessor.)