| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
| TEST_RC_REPLACEMENTS = { | ||
| 'FORMAT': { | ||
| 'max-module-lines': 1960, | ||
| 'max-module-lines': 2000, |
| page_token=page_token, max_results=max_results, | ||
| page_start=_rows_page_start) | ||
| iterator.schema = self._schema | ||
| # Over-ride the key used to retrieve the next page token. |
|
|
||
|
|
||
| def _row_from_json(row, schema): | ||
| """Convert JSON row data to row w/ appropriate types. |
| """Convert JSON row data to row w/ appropriate types. | ||
|
|
||
| :type row: dict | ||
| :param row: |
| return _row_from_json(resource, iterator.schema) | ||
|
|
||
|
|
||
| # pylint: disable=unused-argument |
| max_results=MAX, | ||
| page_token=TOKEN) | ||
| iterator = table.fetch_data( | ||
| client=client2, max_results=MAX, page_token=TOKEN) |
|
@tseaver Can you weigh in here? I'm especially curious how you feel about fetch_data (both in Table and QueryResults) and QueryResults.run. |
Sorry, something went wrong.
+0 for adding it to fetch_data: those methods currently return a 3-tuple, row_data, total_rows, page_token, which means we would have to choose what to do with the total_rows count. -1 for adding it to run: that doesn't return row data, paged or not. |
Sorry, something went wrong.
Check out the implementation, I put total_rows on iterator.page. |
Sorry, something went wrong.
| """ | ||
| total_rows = response.get('totalRows') | ||
| if total_rows is not None: | ||
| page.total_rows = int(total_rows) |
|
LGTM, once you decide about my question about where total_rows should be exposed. |
Sorry, something went wrong.
|
@tseaver I'll put total_rows on both once back at keyboard. Now that you've seen the implementation, does it seem appropriate to change QueryResults.fetch_data over as well? |
Sorry, something went wrong.
|
@tseaver I started writing the code to put total_rows on the Iterator instance and realized something. If while paging, the first request has totalRows: 1200 and the second request somehow has the key missing, then on the second page we'd either have to del iterator.total_rows or iterator.total_rows = None or have an invalid value. Given this scenario, it seems like my_iter.page.total_rows is the only real correct place for total_rows since it is actually a page-specific value (it may even change between pages if the backend is processing more rows between requests?) |
Sorry, something went wrong.
|
@dhermes For queries, the docs say totalRows is only present on a page of results if the query has already completed: we can therefore presume that i will not change. For tables, the docs say only that totalRows represents "[t]he total number of rows in the complete table." We would have to ask the back-end team whether the page_token encodes a "timestamped" cursor which would make totalRows constant across pages, even if new values were inserted into the table in the meanwhile. |
Sorry, something went wrong.
|
@fhoffa Can you chime in on how stable the totalRows value is for tabledata? |
Sorry, something went wrong.
In particular, isolating the logic useful to work on a single row.
Also fixing BigQuery system test in the process.
|
@tseaver I put total_rows only on the Iterator and just allowed it to be None if missing in the response. |
Sorry, something went wrong.
Move BigQuery list_ methods to use iterators
| Back | FazBrowse Home | New Git URL |
Follow up to #2561. This only covers Dataset.list_tables() and Table.fetch_data(). It may also be "correct" to use an Iterator in
but I wanted to get eyes on this change first / opinion from the original author (@tseaver) before moving forward.