Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merge 'master' from upstream #29

Merged
merged 14 commits into from Apr 25, 2019
Merged

Conversation

jrolli
Copy link
Collaborator

@jrolli jrolli commented Apr 25, 2019

This PR merges in the latest changes in the master branch from upstream and resolves several API conflicts in the tests that utilize SqlTable (versioning is not upstream).

@jrolli jrolli added the In Progress This PR is in progress and not ready to be reviewed label Apr 25, 2019
@jrolli jrolli requested a review from yashNaN April 25, 2019 14:51
@jrolli jrolli added ReadyForReview This PR is ready for review and removed In Progress This PR is in progress and not ready to be reviewed labels Apr 25, 2019
* | ... |
* -----------------------------------------------------------------------
* -------------------------------------------------------------------------------------
* | size | max_tuples | num_tuples | num_cols | attr_end[4] | col_id1 | col_id2 | ... |
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is attr_end supposed to be the array of attribute size? Why isn't this documented as attr_sizes?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nvm I get it, it's storing where the boundaries are.

@@ -5,6 +5,17 @@
#include <utility>
#include <vector>
namespace terrier::storage {
const uint32_t ProjectedColumns::AttrSizeForColumn(uint16_t col_id) {
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

attr_ends_ seems to be only for getting attr sizes, so why not directly just store attr size? Or would attribute size potentially be too large to fit them all in the header?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ignore this, John you're a genius. It make sense

// columns size by tracking the locations of the attribute size boundaries.
// Therefore, we only need to track 4 locations because the exterior bounds
// are implicit.
#define NUM_ATTR_BOUNDARIES 4
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Everything makes sense now regarding all the questions I had about attr_ends_, you're a genius.

Copy link
Owner

@yashNaN yashNaN left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me, the questions I had were answered by your timely code comments.

@jrolli jrolli merged commit 76a31af into yashNaN:schema_change Apr 25, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ReadyForReview This PR is ready for review
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants