Skip to content

Conversation

@TheNeuralBit
Copy link
Member

No description provided.

let found: boolean = false;
for (let [id, vector] of readDictionaries(schema.fields(index), batch, state, dictionaries)) {
dictionaries[id] = dictionaries[id] && dictionaries[id].concat(vector) || vector;
found = true;
Copy link
Contributor

@trxcllnt trxcllnt Oct 20, 2017

Choose a reason for hiding this comment

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

@TheNeuralBit I think we can break here, instead of using a flag? IIRC the readDictionaries function returns as soon as it finds a dictionary, or yields nothing if it doesn't

Copy link
Member Author

@TheNeuralBit TheNeuralBit Oct 20, 2017

Choose a reason for hiding this comment

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

but breaking here would only break out of the for, not the while, right?
it does seem like there should be a cleaner way, since readDictionaries will return at most one vector. Is it necessary to return the id? shouldn't it always equal batch.id?
Maybe readDictionaries could just return vector if found, otherwise null

Copy link
Contributor

@trxcllnt trxcllnt Oct 20, 2017

Choose a reason for hiding this comment

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

@TheNeuralBit yeah, that's right. I think both the for loop over the readDictionaries iterator and the return [id, vector] tuple are remnants from when my understanding was that DictionaryBatches could contain more than one DictionaryVector.

Since that was a misunderstanding, it totally makes sense to change the readDictionaries signature to return DictionaryVector | void instead of Iterator<[id, vector]>, and not loop. Do you mind updating the PR to reflect this?

Copy link
Member Author

Choose a reason for hiding this comment

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

sure!

Copy link
Contributor

@trxcllnt trxcllnt left a comment

Choose a reason for hiding this comment

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

use break instead of branching

Copy link
Contributor

@trxcllnt trxcllnt left a comment

Choose a reason for hiding this comment

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

👍 thanks @TheNeuralBit!

@wesm
Copy link
Member

wesm commented Oct 21, 2017

Is this caught by any tests? or will we be stuck until we can run JS in the integration test suite?

@trxcllnt
Copy link
Contributor

trxcllnt commented Oct 21, 2017

@wesm I don't think so, but I can add the arrow file @TheNeuralBit uploaded to JIRA to the tests. That should hold us over until we can run the integration suite.

@wesm
Copy link
Member

wesm commented Oct 21, 2017

No worries. I would say the sooner we can at least feed the integration test files to JS to say "can you read this?" the better

@wesm
Copy link
Member

wesm commented Oct 21, 2017

+1

@asfgit asfgit closed this in 989aba6 Oct 21, 2017
@wesm wesm deleted the ARROW-1698 branch October 21, 2017 11:52
@wesm
Copy link
Member

wesm commented Oct 21, 2017

Sorry I should have asked you to rerun the build since Travis CI had some issues yesterday. master is currently broken

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants