| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
| import copy | ||
| import re | ||
| import threading | ||
| import tqdm |
There was a problem hiding this comment.
This needs to be an optional import. See:
python-bigquery/google/cloud/bigquery/table.py
Lines 39 to 42 in 20f473b
Sorry, something went wrong.
| rows._preserve_order = _contains_order_by(self.query) | ||
| return rows | ||
|
|
||
| def _get_progress_bar(self, progress_bar_type, description, total, unit): |
There was a problem hiding this comment.
Seems like this is very close to the logic in table.py
python-bigquery/google/cloud/bigquery/table.py
Line 1374 in 20f473b
I'd suggest creating a _tqdm_helpers.py module similar to our pandas helpers to hold this logic for both Table and Job logic.
Sorry, something went wrong.
…into bigquery_issue_343
| ..versionadded:: 1.17.0 | ||
| """ | ||
| return self.result().to_arrow( | ||
| if self.query_plan and progress_bar_type: |
There was a problem hiding this comment.
Is this logic necessary if we are calling to_arrow? Can't we rely on to_arrow's progress bar support?
Sorry, something went wrong.
There was a problem hiding this comment.
Sorry, didn't get this point, are you talking about table.to_arrow() progress bar support?
Sorry, something went wrong.
There was a problem hiding this comment.
Oh, I was getting this confused with RowIterator, where to_dataframe relies on to_arrow's progress bar support. I do wonder if some of this "waiting for the query to finish" logic could be refactored into a _tqdm_helpers.py function, since it should be identical between to_dataframe and to_arrow
Sorry, something went wrong.
| """ | ||
| return self.result().to_dataframe( | ||
| query_plan = self.query_plan | ||
| if query_plan and progress_bar_type: |
There was a problem hiding this comment.
query_plan can get updated as the job progresses. I'd prefer if this always created a progress bar, but had a generic message when the job is still pending and there isn't a query plan.
Sorry, something went wrong.
| ) | ||
|
|
||
| try: | ||
| query_result = self.result(timeout=0.5) |
There was a problem hiding this comment.
We should make constants for this (PROGRESS_BAR_UPDATE_INTERVAL, for example)
Sorry, something went wrong.
There was a problem hiding this comment.
Looking good. A few nits regarding naming and indentation.
Sorry, something went wrong.
| return None | ||
|
|
||
|
|
||
| def _query_job_result_helper(query_job, progress_bar_type=None): |
There was a problem hiding this comment.
Let's use active verbs in this helper name.
| def _query_job_result_helper(query_job, progress_bar_type=None): | |
| def wait_for_query(query_job, progress_bar_type=None): |
Sorry, something went wrong.
|
|
||
| def _query_job_result_helper(query_job, progress_bar_type=None): | ||
| """Return query result and display a progress bar while the query running, if tqdm is installed.""" | ||
| if progress_bar_type: |
There was a problem hiding this comment.
We can reduce the level of indentation if we exit early. Also, I think we'll want to pass through some keyword arguments to result(), correct?
| if progress_bar_type: | |
| if progress_bar_type is None: | |
| return query_job.result() |
Aside (not relevant for this PR): we'll eventually want to pass additional arguments to result() whenever we implement #296
Sorry, something went wrong.
| _PROGRESS_BAR_UPDATE_INTERVAL = 0.5 | ||
|
|
||
|
|
||
| def _get_progress_bar(progress_bar_type, description, total, unit): |
There was a problem hiding this comment.
We want to use these helpers from other modules, let's remove the (redundant because of private module) leading _.
| def _get_progress_bar(progress_bar_type, description, total, unit): | |
| def get_progress_bar(progress_bar_type, description, total, unit): |
Sorry, something went wrong.
| progress_bar = _get_progress_bar( | ||
| progress_bar_type, "Query is running", 1, "query" | ||
| ) | ||
| if query_job.query_plan: |
There was a problem hiding this comment.
This should be one level deeper. I'd like to see the while True loop, even when query_plan is not initially populated.
Sorry, something went wrong.
…into bigquery_issue_343
There was a problem hiding this comment.
I'd expect the while loop to contain the following steps:
Sorry, something went wrong.
| """Return query result and display a progress bar while the query running, if tqdm is installed.""" | ||
| if progress_bar_type is None: | ||
| query_result = query_job.result() | ||
| else: |
There was a problem hiding this comment.
I meant that you could return query_job.result() here. The else statement is then unnecessary, saving us 1 level of indentation.
Sorry, something went wrong.
| i += 1 | ||
| continue | ||
| else: | ||
| query_result = query_job.result() |
There was a problem hiding this comment.
We need a timeout here. It's not clear to me why the above try block is even in the if statement.
Sorry, something went wrong.
There was a problem hiding this comment.
Looks like the only difference is the presence of total, which could be set to a default value in the case where query_plan is not present.
Sorry, something went wrong.
| while True: | ||
| if query_job.query_plan: | ||
| total = len(query_job.query_plan) | ||
| query_job.reload() # Refreshes the state via a GET request. |
There was a problem hiding this comment.
Wouldn't we only want to call reload after result times out?
Also, why would we only call reload inside this if statement? The job might not have a query_plan until after reload is called in many cases.
Sorry, something went wrong.
|
system test failed not related to changes. |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
Fixes #343
PR open for the feedback and suggestions.
Currently implemented for 'QueryJob.to_arrow' method
When the cacheHit for result is true at time query_plan is blank so can't implement progress bar.