Port table_slice API to FlatBuffers #1140
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
dominiklohmann
added
feature
This was referenced Nov 4, 2020
dominiklohmann
force-pushed
the
epic/flatbuffers-persistence-table-slices
branch
from
cb8ed32
to
7ac7acf
Compare
This was referenced Nov 9, 2020
dominiklohmann
force-pushed
the
epic/flatbuffers-persistence-table-slices
branch
from
5856ff4
to
7508e01
Compare
dominiklohmann
force-pushed
the
epic/flatbuffers-persistence-table-slices
branch
from
7508e01
to
daa4363
Compare
The corresponding row_major_matrix_table_slice_builder.hpp file was removed in an earlier commit, but this file was left in by accident.
This is a first step towards removing the header altogether.
We previously had both `table_slice::column_view` and `table_slice_column` with slightly different behavior. This removes the `table_slice::column_view` and makes it behave as expected with the new API. Additionally this removes the `table_slice::column(...)` functions from the `table_slice` API, because they are just covered by the constructors of `table_slice_column`.
This supersedes `table_slice::row_view` and allows for removing `table_slice::row(...)`, because the function is covered by the constructor of `table_slice_row`.
It was not even used anywhere—we just forgot to remove it.
Additionally, this sorts the functions in table_slice.hpp and table_slice.cpp in a consistent way.
The agreed upon design for the new table_slice API has `table_slice::layout()` return by value. This removes some code that would then probably not work correctly.
At this point in time this is strictly a pessimization, but we need to change this down the road and at this point it is easy to detect the required changes.
The `table_slice::inspect` function must go through the constructor that handles the instance counting when loading table slices from a `caf::message`.
The offset being in the `table_slice` encoding-specific FlatBuffers tables was the only reason why we required support for mutable FlatBuffers. This commit changes `table_slice` to hold the offset in-memory. The offset is now assigned by the importer on import and by the segment on lookup.
The FlatBuffers API guarantees that the encoding pointers are not `nullptr`, so we might as well dereference them in the visitor function already.
dominiklohmann
force-pushed
the
epic/flatbuffers-persistence-table-slices
branch
from
4e48f8e
to
f3fc26b
Compare
This was referenced Nov 15, 2020
Closed
tobim
approved these changes
Nov 15, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
📔 Description
Transform the
table_sliceAPI to use FlatBuffers for persistence, enabling versioning of table slice encodings and sharing ownership between segments and contained table slices.🗺️ Implementation Status
table_sliceAPI Cleanup table_slice API #1141table_sliceAPI Switch to the new table_slice API #1148📝 Checklist
🎯 Review Instructions
Because of the sheer size of this change, this PR is split into multiple PRs that will be merged into this epic branch. After all merge commits are through, this PR will contain fixups only, which are best reviewed commit-by-commit.