Metabase sync fails with Code: 51. DB::Exception: Empty list of columns in SELECT query. (EMPTY_LIST_OF_COLUMNS_QUERIED) #256
Comments
|
The only major change in the connection between 0.47 and 0.50 I could think of, aside from the JDBC driver upgrade, is this setting: The behavior on both versions of the analyzer is slightly different on 24.6 (but it looks like they still indicate the same issue):
I am currently not sure that it is the driver bug, either. |
|
@slvrtrn I see you marked this as "blocked-by-clickhouse". Do you know if there is any movement on this? Or a related issue in ClickHouse that I could follow & bump (apart from the one I just linked)? Thanks! |
|
I added the flair because I too think that this could be related to ClickHouse/ClickHouse#65402 |
|
@novikd, thanks! Theoretically, it could be possible to override the entirety of https://github.com/metabase/metabase/blob/v1.50.23.1/src/metabase/driver/sql_jdbc/sync/describe_table.clj#L205-L217, but it contains a significant amount of logic from the private methods, so it does not look like a good idea. Additionally, we need to get So I am still not sure how to resolve this on the driver side. |
|
@slvrtrn Why does Metabase try to query parameterized views? It just doesn't make any sense. Parameterized view is almost a user-defined table function.
|
This is part of the database introspection. This query allows Metabase to figure out column names and types from the JDBC result set (which is supposed to be always empty, it just provides the column metadata) so that they can be displayed in the available tables list in the UI. The more I think about it, the more it looks like we should just exclude parametrized views from the database introspection. However, this is strange:
Especially given that the default Metabase introspection query was never changed on the driver side. |
This can be explained by the change in parameterized views implementation in 24.2.
Something definitely changed in
It's strange to use IMHO, Metabase should handle parametrized views differently. |
It kind of is, but that's the thing with how JDBC drivers work. With an empty select, you still have ResultSetMetadata, which can be used to fetch the information about the columns and their types (not CH types, but their mapping to the standard JDBC ones which are then used internally). Then, for each specific JDBC type, we provide a function specifying how to process it, for example: https://github.com/ClickHouse/metabase-clickhouse-driver/blob/1.50.6/src/metabase/driver/clickhouse_qp.clj#L441-L449 Using |
|
@slvrtrn I mean that JDBC drivers should not try to infer a schema for parameterized view. Let's look at it from another point: So in my opinion, parameterized views should be skipped. I don't know if there's any other way to show them in Metabase UI, but we definitely should treat them the same way as table functions. |
We started getting Our metabase didn't change then (it was So probably it was some patch tier change in clickhouse that was backported from |
Describe the bug
Not sure if this is something that the metabase-clickhouse-driver can fix or if it needs to be reported to metabase/metabase.
We recently upgraded ClickHouse from 24.1 to 24.5 and also Metabase from 0.47 to 0.50. After the upgrades, we noticed that the column sync now fails with:
By checking the query log, we identified that this was particularly failing for a parameterized view when running
This leads us to believe it has something to do with ClickHouse/ClickHouse#65402. Though, by unfolding the order of events, it seemed that this was only happening with the combination of both, the Metabase and the ClickHouse upgrade:
Steps to reproduce
Expected behaviour
Parameterized views should not cause the full sync to fail
Error log
Stack trace
Configuration
Environment
1.50.10.50.9ClickHouse server
24.5.4.49CREATE TABLEstatements for tables involved: any parameterized view, e.g.CREATE VIEW delete_me_param_view AS SELECT * FROM system.clusters WHERE cluster = {cluster:String}The text was updated successfully, but these errors were encountered: