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
We can only mark models materialized by default for cases when input and output connector are different.
But for clickhouse since we rely on clickhouse connectors to ingest all data it is not possible for us to set that default.
This leads to very hard to know issues where clickhouse keeps pulling data from external source for every query.
The same issue will also be present in duckDB when we move to its internal connectors.
The text was updated successfully, but these errors were encountered:
I wonder if there's a way we can analyze a query for external dependencies? For example in DuckDB, maybe creating a temporary view with SET enable_external_access=false?
The same issue will also be present in duckDB when we move to its internal connectors.
For backwards compatibility at least, this can be solved by having type: source emit a model where materialize: true.
For example in DuckDB, maybe creating a temporary view with SET enable_external_access=false
Yes this can be evaluated for duckdb. Though enable_external_access once set to false can't be set to true and is a global configuration. We may need to do throw away the write handle once we do this check.
We can only mark models materialized by default for cases when input and output connector are different.
But for clickhouse since we rely on clickhouse connectors to ingest all data it is not possible for us to set that default.
This leads to very hard to know issues where clickhouse keeps pulling data from external source for every query.
The same issue will also be present in duckDB when we move to its internal connectors.
The text was updated successfully, but these errors were encountered: