You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Elsewhere I found that calling fetch all() after a create temp view resulted in the following stack trace:
```
Traceback (most recent call last):
2 File "<stdin>", line 1, in <module>
3 File "/Users/niallegan/opt/miniconda3/lib/python3.7/site-packages/databricks/sql/client.py", line 318, in fetchall
4 return self.active_result_set.fetchall()
5 File "/Users/niallegan/opt/miniconda3/lib/python3.7/site-packages/databricks/sql/client.py", line 522, in fetchall
6 return self._convert_arrow_table(self.fetchall_arrow())
7 File "/Users/niallegan/opt/miniconda3/lib/python3.7/site-packages/databricks/sql/client.py", line 496, in fetchall_arrow
8 results = self.results.remaining_rows()
9 File "/Users/niallegan/opt/miniconda3/lib/python3.7/site-packages/databricks/sql/utils.py", line 27, in remaining_rows
10 slice = self.arrow_table.slice(self.cur_row_index, self.n_valid_rows - self.cur_row_index)
11 File "pyarrow/table.pxi", line 1125, in pyarrow.lib.Table.slice
12IndexError: Offset must be non-negative
```
The problem was that the startRowOffset was after what we requested.
However, it turns out that client side we should be ignoring and not setting `startRowOffset` since Thrift uses FETCH_NEXT by default. This PR changes to make `FETCH_NEXT` explicit and stop tracking the row offset.
I also took this opportunity to improve unit test coverage for dealing with the arrow batches and row counts.
* Manually running SELECT * from temp view test against prod
* New smoke test for SELECT * from temp view
* Increase unit test coverage
- Did you add usage logs or metrics? Please mention them here.
- Create dashboards or monitoring notebooks? Please link them here.
- See http://go/obs/user for docs on our observability tools.
0 commit comments