-
Notifications
You must be signed in to change notification settings - Fork 98
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
refactor: first refactor of createReadStream #1118
refactor: first refactor of createReadStream #1118
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this needs a bit more refactoring. Currently this creates a circular dependency between TableUtils and Table, which is a bad code smell
This circular dependency is just a result of some cleanup that wasn't done. I have added a commit so that there aren't circular dependencies anymore which turned out to be a fairly simple change. If you want to change the utils class name then we can do that too. |
More refactoring is done in the next two PRs. |
If you want to see a larger refactor then take a look at this PR: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
This is the first of many PRs to refactor createReadStream. We need to reduce the size of this function so that we can work with it and so that adding retry features is easier.
API surface affected:
request
function in index.ts:For tests that look at the API surface:
https://github.com/googleapis/nodejs-bigtable/blob/main/test/table.ts#L539
https://github.com/googleapis/nodejs-bigtable/blob/main/system-test/read-rows.ts#L154
In this PR, we pull out code to calculate the
ranges
variable increateReadStream
into a separate function. The main motivation for this besides reducing thecreateReadStream
function size is to take code, which calculatesranges
initially and move it into a separate function since this initial calculation has nothing to do with what happens in the rest of the function after that. This conceptually tells the code reader that onlyoptions
is needed to calculate ranges initially and that all code used to calculateranges
initially can be ignored if the reader is only interested in what happens in the rest of the function.So....
https://github.com/googleapis/nodejs-bigtable/pull/1118/files#diff-6400d8602f0855266c743f4fb031e97ac9cf07f9dcddfba03833b6f04d547a5eL750 to https://github.com/googleapis/nodejs-bigtable/pull/1118/files#diff-6400d8602f0855266c743f4fb031e97ac9cf07f9dcddfba03833b6f04d547a5eL780)
should just be a cut/paste of
https://github.com/googleapis/nodejs-bigtable/pull/1118/files#diff-2490acae1e166b5d2477465b3ee761d0857374c409d215d0363d626c665e80d6R20 to
https://github.com/googleapis/nodejs-bigtable/pull/1118/files#diff-2490acae1e166b5d2477465b3ee761d0857374c409d215d0363d626c665e80d6R48
The only other two minor changes are the changes to the test stub and the change to
createPrefixRange
. The test stub changes which include all the changes intest/table.ts
are necessary as a result of pulling outranges
into a utility function and the way that sinon works in the tests.table.createPrefixRange
delegates its functionality toTableUtils.createPrefixRange
which does the exact same thingtable.createPrefixRange
did (we are just cut/pasting the code), but is something we need to do because of sinon stubs. Basically, sinon gets in the way of just being able to pull code out because it mockscreatePrefixRange
fromTable
, butTableUtils
has a different copy ofTable
so while a test for prefixes should work, in this case the test needs to be slightly modified because it also demands that everything happens inTable
which shouldn't be necessary. But if this is undesirable then we can consider using a private method instead of a utility class.