feat(api_core): provide a 'raw_page' field for page_iterator.Page #9486
Conversation
Some paginated response messages include additional fields that users may wish to inspect.
|
Thanks @software-dov, any chance that this would be doable off of |
|
My two main concerns in no particular order are
With "ease of implementation" being a non-voting tie-breaker. Making the raw page (or transparently mapped attributes via getattr) visible from With the microgenerator surface, touching internal fields of the page forces you to do your own pagination, something like while True:
response = client.paginated_method(request)
handle_page(response)
if not response.next_page_token:
break
request.page_token = response.next_page_tokenwhich doesn't look great to me. Again, modulo complications with flattening, this is the interface that exposing raw_page in the iterator would be forced to mimic. I guess I'm not sure I understand the circumstances where the topmost level raw_page is preferable to response = client.paginated_method(request)
for p in response.pages:
handle_page(p)
for elt in p:
handle_element(elt) |
|
Open review and design bump |
Some paginated response messages include additional fields that users
may wish to inspect. This change stores the raw page when constructing a page_iterator.Page and provides an accessor.
In addition to the new and modified unit tests, hand experimentation generates expected behavior:
prints individual pages.