Fixed
Status Update
No update yet.
Comments
[Deleted User] <[Deleted User]>
I think it makes a perfect sense as a feature request and is indeed distinct from other issues you referenced. Thanks for filing!
uc...@google.com
I have CCed stakeholders and leaving the feature request assigned to myself for now.
al...@google.com
[Deleted User] <[Deleted User]>
Thanks for accepting this request, having this would be fantastic in my opinion (and my team's)!
[Deleted User] <[Deleted User]>
RE:"Thanks for accepting this request": this is just being brought for consideration. Thanks again for filing the feature request.
[Deleted User] <[Deleted User]>
Any progress on this?
This request is similar tohttps://issuetracker.google.com/issues/72224267
Why are we so interested in this?
Our goal is to build an easy to maintain, basically 'NoETL' datawarehouse pipeline. Everywhere where we have to 'fall back' to Python programming makes the whole pipeline more complex to maintain. Having (parametrized) materialized views that could do a full or partial refresh would really be THE enabler for this.
Basically it would be something like Looker's Persistent Direived Tables, but then with the added abilities to:
-Refresh incrementally
-Fully use time partitioning and table suffixing.
This request is similar to
Why are we so interested in this?
Our goal is to build an easy to maintain, basically 'NoETL' datawarehouse pipeline. Everywhere where we have to 'fall back' to Python programming makes the whole pipeline more complex to maintain. Having (parametrized) materialized views that could do a full or partial refresh would really be THE enabler for this.
Basically it would be something like Looker's Persistent Direived Tables, but then with the added abilities to:
-Refresh incrementally
-Fully use time partitioning and table suffixing.
[Deleted User] <[Deleted User]>
What types of queries do you want to use in the MV?
Using aggregation views to optimize query performance and cost is a different use case than using MV as a workaround to ELT.
Using aggregation views to optimize query performance and cost is a different use case than using MV as a workaround to ELT.
[Deleted User] <[Deleted User]>
#7, for us the use cases would be both ETL and costs optimization queries (fyi, I am the original poster of these request)
IMO the main difference between the two patterns are:
1) ETL type MV's have more joins
2) Cost optimization MV's are simpler / aggregate style queries
In the end, what is important is that it supports the following refresh patterns:
1) easy: a full refresh (truncate / insert pattern). Oracle calls this a full refresh
2) more complex: incremental update, for this to work the insert/update/delete (or merge) has to be driven by a key. Oracle calls this the fast refresh option.
IMO this functionality could / should replace BQ scheduled queries, which I guess won't be a real focus anymore now that cloud composer is here...
IMO the main difference between the two patterns are:
1) ETL type MV's have more joins
2) Cost optimization MV's are simpler / aggregate style queries
In the end, what is important is that it supports the following refresh patterns:
1) easy: a full refresh (truncate / insert pattern). Oracle calls this a full refresh
2) more complex: incremental update, for this to work the insert/update/delete (or merge) has to be driven by a key. Oracle calls this the fast refresh option.
IMO this functionality could / should replace BQ scheduled queries, which I guess won't be a real focus anymore now that cloud composer is here...
so...@google.com
Is there any progress with regards to this topic? Having materialised views in BigQuery would be the trigger for us to move away from our current solution, onto the BQ platform....
so...@google.com
an...@gmail.com
Tjeerd - please sync up with your Google Cloud account team to share roadmap under an NDA.
so...@google.com
Is materialized view in early-access stage?
We just saw it in gcloud CLI and would like to try this feature.
We just saw it in gcloud CLI and would like to try this feature.
[Deleted User] <[Deleted User]>
How do we get access to the experimental materialized view feature?
so...@google.com
please sync up with your Google Cloud account team to share roadmap under an NDA.
so...@google.com
Had hoped something would be announced at Google Next '19, guess we'll have to wait :-(
so...@google.com
Yep, would love this.
so...@google.com
an...@gmail.com
We are looking for this feature too, and it often comes up when we evaluate bq vs snowflake. Would be great if bq can support MVs.
an...@gmail.com
with bq mk this is sort of possible (transfer jobs), something like:
bq mk \
--transfer_config \
--target_dataset='target_dataset' \
--display_name='schedule_name' \
--params='{"query":"SELECT xyz FROM table","destination_table_name_template":"target_table","write_disposition":"WRITE_APPEND"}' \
--data_source='scheduled_query' \
--schedule='every day 01:00'
bq mk \
--transfer_config \
--target_dataset='target_dataset' \
--display_name='schedule_name' \
--params='{"query":"SELECT xyz FROM table","destination_table_name_template":"target_table","write_disposition":"WRITE_APPEND"}' \
--data_source='scheduled_query' \
--schedule='every day 01:00'
Description
AI-181.5281.24.32.4860949, JRE 1.8.0_152-release-1136-b04x64 JetBrains s.r.o, OS Mac OS X(x86_64) v10.13.5 unknown, screens 2560x1440, 1440x900
Android Gradle Plugin: 3.2.0-beta02
Gradle: 4.6
I don't remember this happening before, but whenever I switch branches or do a Gradle Sync, often the Project>Android tree refreshes many dozens of times. I had thought this might be related to the .idea/workspace.xml so I would delete that and restart the IDE, but that doesn't seem to stop this from happening. I've disabled workspace resuming when switching branches, but that doesn't stop this behaviour. Sorry, I can't really explain this very well. I'll try and attach a movie to show this.