Replies: 2 comments 5 replies
-
|
This works for python users, but C++ arrow API users will have to compute |
Beta Was this translation helpful? Give feedback.
1 reply
-
|
#506 is the approach I've been thinking about. It has more code reuse and less terminology, but it's not complete.
|
Beta Was this translation helpful? Give feedback.
4 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
A few topics to discuss:
vs
Metadata and versioning needed for on-disk data structures for sure. Not clear for in-memory arrow based variants
Parquet and Arrow are well known in the industry. We tried to call this
graph-stdand quickly came to the conclusion that it was a bad choice (people can't google it). Icebug-format was chosen since it's unique enough, associated with the sister project icebug and logical (ice = frozen = immutable).However, icebug-disk (icedisk) or icebug-mem (icemem) are generally not well known. People don't recognize them and hard to lookup. This could change if the ideas are widely implemented in the industry. Too early to tell.
We have (in-memory vs persistent) * (flat tuples vs CSR) * (node vs rel tables) = 8 different combinations of very similar code. How do we manage this complexity balancing code reuse vs avoiding complex control flow.
More discussion in #496 (+1650 lines of code)
Beta Was this translation helpful? Give feedback.
All reactions