Remove usage of __TABLES__
#1213
Conversation
|
Key comments from description of #364 that we'll want to consider sufficiently prior to merging this PR. Trade-offs and outstanding questionsThe problem is that it doesn't contain
|
|
Given the tradeoffs, I'm quite weary of removing displaying row count and size given how many folks have found that to be helpful. |
| on materialized_views.table_catalog = tables.project_id | ||
| and materialized_views.table_schema = tables.dataset_id | ||
| and materialized_views.table_name = tables.table_id | ||
| partitions.total_logical_bytes as size_bytes, |
There was a problem hiding this comment.
@dbeatty10 @amychen1776 It looks like you're saying that we're not getting the size nor the row count. Are these two fields (partitions.total_logical_bytes and partitions.total_rows) coming through as 0?
There was a problem hiding this comment.
I haven't tried out this PR, so I'm not sure how partitions.total_logical_bytes and partitions.total_rows are coming through. How are they coming through for you @mikealfare ?
It would be awesome if they successfully preserve non-null and non-zero values for size_bytes and total_rows!
There was a problem hiding this comment.
Sounds like we need an integration test or two. I know I worked on this when I thought this was the source of a bug a few weeks ago. It turned out to not be the case though, so I left it there. @jtcohen6 @amychen1776, would you consider prioritizing this for the upcoming sprint so that we could capture the value here? We would get two main things:
- get off of
__TABLES__, which is an undocumented dependency (we should be usingTABLES - reduce permissions required to run
dbt-bigquery
resolves #113
rebase of #364