Thank you everyone.
On Sat, Feb 27, 2016 at 2:00 PM, Jason Altekruse
wrote:
> Wes it right, I should have qualified my statement about the Drill code. As
> is stated in the Arrow repo initial design docs, the exact memory layout is
> not finalized. That being said, while the format is designed t
Wes it right, I should have qualified my statement about the Drill code. As
is stated in the Arrow repo initial design docs, the exact memory layout is
not finalized. That being said, while the format is designed to be used
in-memory, it doesn't have the same sticking point about backwards
compatib
The layering of C++ container classes and algorithms will not have any
bearing of the physical memory layout of the arrays. If we were
programming in C, a primitive array could be represented something
like:
typedef struct array_t {
int type;
int32_t length;
int32_t null_count;
const uint8
Note that we have not prioritized building a lot of new software for
Arrow (outside of the basic C++ implementation and the Drill Java
extraction) because there are a number of details that we need to work
out as a group in the coming weeks:
- Lingering physical memory layout questions, see workin
The java version of the Arrow project is reasonably consumable. The code
was extracted from the Apache Drill project which has been using this
columnar representation since its inception.
Steven Phillips is working on finishing the extraction of the necessary
interfaces from Drill over in his fork
