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

Re-architect Iterator class. #2531

Merged
merged 13 commits into from
Oct 14, 2016
Merged

Conversation

dhermes
Copy link
Contributor

@dhermes dhermes commented Oct 12, 2016

This PR should definitely reviewed commit-by-commit.

Primary changes are:

  • Have an iterable Page base-class for iterating over a single page of a result set
  • Move most custom iterator logic back up into the base page and iterator classes

@dhermes dhermes added api: storage Issues related to the Cloud Storage API. api: core api: cloudresourcemanager Issues related to the Resource Manager API. labels Oct 12, 2016
@googlebot googlebot added the cla: yes This human has signed the Contributor License Agreement. label Oct 12, 2016
Intended to hold and slice up state that has already been
retrieved from the server.
This is so that the owned items iterator management could
be done on the base class and the child classes just
need to worry about converting the JSON values to whatever
type is required.
This state can never happen since a StopIteration will occur
before the method would ever be called without a token.
Also doing a tiny re-org in constructor to separate the
attributes which change and those which don't.
Making JSON API call helpers non-public. This reduces the
interface to methods relevant to iterating.
Copy link
Contributor

@theacodes theacodes left a comment

Choose a reason for hiding this comment

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

My one concern is how a service like datastore will work.

This abstraction seems to completely hides cursors, but cursors often need to be passed between client and server in datastore (think client-side pagination). I'm wondering how that would fit in here?

"""The :class:`Page` is an iterator."""
return self

def _item_to_value(self, item):

This comment was marked as spam.

This comment was marked as spam.

return self._num_items

@property
def remaining(self):

This comment was marked as spam.

This comment was marked as spam.

@dhermes
Copy link
Contributor Author

dhermes commented Oct 14, 2016

My one concern is how a service like datastore will work.

Datastore has it's own specialized Iterator. For the time being, the google.cloud.iterator.Iterator class is for JSON-based APIs that define a nextPageToken in response pages.

Though a "next step" would be to make the iterator support gRPC / GAPIC generated classes, so we may be able to tackle datastore there. (Just not in this PR.)

@daspecster
Copy link
Contributor

Sorry I haven't responded on this @dhermes. I don't have much feedback though.

You actually just answered the question I did have.

Though a "next step" would be to make the iterator support gRPC / GAPIC generated classes, so we may be able to tackle datastore there. (Just not in this PR.)

@theacodes
Copy link
Contributor

LGTM

@dhermes dhermes merged commit 9a5ddd5 into googleapis:master Oct 14, 2016
@dhermes dhermes deleted the revamp-iterator branch October 14, 2016 19:09
dhermes added a commit to dhermes/google-cloud-python that referenced this pull request Oct 14, 2016
This is to lower the burden on implementers. The previous
approach (requiring a Page and Iterator subclass) ended
up causing lots of copy-pasta docstrings that were just
a distraction.

Follow up to googleapis#2531.
richkadel pushed a commit to richkadel/google-cloud-python that referenced this pull request May 6, 2017
richkadel pushed a commit to richkadel/google-cloud-python that referenced this pull request May 6, 2017
This is to lower the burden on implementers. The previous
approach (requiring a Page and Iterator subclass) ended
up causing lots of copy-pasta docstrings that were just
a distraction.

Follow up to googleapis#2531.
parthea pushed a commit that referenced this pull request Jun 4, 2023
This is to lower the burden on implementers. The previous
approach (requiring a Page and Iterator subclass) ended
up causing lots of copy-pasta docstrings that were just
a distraction.

Follow up to #2531.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api: cloudresourcemanager Issues related to the Resource Manager API. api: core api: storage Issues related to the Cloud Storage API. cla: yes This human has signed the Contributor License Agreement.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants