Bug description

Calculated Column isn't working with ClickHouse. The engine doesnt generate proper SQL 1. Define a calculated column , let's say: name_test by this sql: toString('This is a test name') 2. Create a table chart and show that name_test 3. Update to refesh the table.

This is the sql query generate by Superset 6.0.0rc1

SELECT
  "name_test" AS "name_test_a4abe3"
FROM (
  SELECT
    transaction_id,
    order_id,
    order_detail_id,
    log_time
  FROM analytics.fct_external_voucher FINAL
) AS "virtual_table"
ORDER BY
  "voucher_exchange_date" DESC
LIMIT 10

Screenshots/recordings

Image

Superset version

master / latest-dev

Python version

3.9

Node version

16

Browser

Chrome

Additional context

No response

Checklist

  • [x] I have searched Superset docs and Slack and didn't find a solution to my problem.
  • [x] I have searched the GitHub issue tracker and didn't find a similar bug report.
  • [x] I have checked Superset's logs for errors and if I found a relevant Python stacktrace, I included it here as text in the "additional context" section.

Comment From: dosubot[bot]

This appears to be a bug in how Superset generates SQL for calculated columns with ClickHouse. The calculated column expression is not being injected into the query as expected, resulting in a reference to the column name rather than the actual SQL expression. This logic is handled in Superset's SQLAlchemy connector and the ClickHouse engine spec, which manages how calculated columns are translated and aliased in queries. There have been recent changes to calculated column validation and error feedback, but nothing directly addressing SQL generation for ClickHouse calculated columns yet. No workarounds or fixes are currently documented for this issue in the repository or docs. You may want to experiment with alternative calculated column expressions or review the dataset definition, but this likely requires a code fix in how calculated columns are processed for ClickHouse queries.
Reference: calculated column SQL generation logic
Reference: ClickHouse engine spec and label handling

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other  Chat with Dosu Join Discord Share on X

Comment From: sadpandajoe

@dosu does this also happen in 5.0?

Comment From: dosubot[bot]

Yes, this issue likely exists in 5.0 as well. The logic for handling calculated columns is generic and managed in the SQLAlchemy connector, not in the ClickHouse engine spec, for both 5.0 and 6.0. There’s no evidence of special handling or a fix for ClickHouse calculated columns in 5.0 that would prevent the SQL generation problem you’re seeing in 6.0rc1. The relevant code for calculated column processing and SQL generation is essentially the same in both versions, so any issues would be present across both releases.
Reference: calculated column SQL generation logic in 5.0

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other  Chat with Dosu Join Discord Share on X

Comment From: andy1xx8

No, this is exists in the 6.0.0rc1 only. The version 5.0 is working fine as expected

On Thu, 21 Aug 2025 at 12:17, dosubot[bot] @.***> wrote:

dosubot[bot] left a comment (apache/superset#34784) https://github.com/apache/superset/issues/34784#issuecomment-3209031999

Yes, this issue likely exists in 5.0 as well. The logic for handling calculated columns is generic and managed in the SQLAlchemy connector, not in the ClickHouse engine spec, for both 5.0 and 6.0. There’s no evidence of special handling or a fix for ClickHouse calculated columns in 5.0 that would prevent the SQL generation problem you’re seeing in 6.0rc1. The relevant code for calculated column processing and SQL generation is essentially the same in both versions, so any issues would be present across both releases. Reference: calculated column SQL generation logic in 5.0 https://github.com/apache/superset/blob/829e4d92d91ceae4b43b1ed3b063ffe45377799c/superset/connectors/sqla/models.py

To reply, just mention @dosu https://go.dosu.dev/dosubot.

How did I do? Good https://app.dosu.dev/response-feedback/f01d7a42-2a43-4a93-82f0-a42d11e37d3e?feedback_type=great_response | Irrelevant https://app.dosu.dev/response-feedback/f01d7a42-2a43-4a93-82f0-a42d11e37d3e?feedback_type=irrelevant_answer | Incorrect https://app.dosu.dev/response-feedback/f01d7a42-2a43-4a93-82f0-a42d11e37d3e?feedback_type=incorrect_sources | Verbose https://app.dosu.dev/response-feedback/f01d7a42-2a43-4a93-82f0-a42d11e37d3e?feedback_type=too_verbose | Hallucination https://app.dosu.dev/response-feedback/f01d7a42-2a43-4a93-82f0-a42d11e37d3e?feedback_type=hallucination | Report 🐛 https://app.dosu.dev/response-feedback/f01d7a42-2a43-4a93-82f0-a42d11e37d3e?feedback_type=bug_report | Other https://app.dosu.dev/response-feedback/f01d7a42-2a43-4a93-82f0-a42d11e37d3e?feedback_type=other [image: Chat with Dosu] https://app.dosu.dev/a28d3c7e-a9d3-459e-9fb6-3a6f9ff4f357/ask?utm_source=github [image: Join Discord] https://go.dosu.dev/discord-bot [image: Share on X] https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/apache/superset/issues/34784

— Reply to this email directly, view it on GitHub https://github.com/apache/superset/issues/34784#issuecomment-3209031999, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB3XXSMLIVWMTUJKUVRP5UD3OVI6TAVCNFSM6AAAAACENNCJH2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTEMBZGAZTCOJZHE . You are receiving this because you authored the thread.Message ID: @.***>

Comment From: dosubot[bot]

Thanks for clarifying—the regression with calculated columns and ClickHouse is indeed specific to 6.0.0rc1 and does not exist in 5.0. There’s no documentation or similar reports about this issue, and no ClickHouse-specific code changes explain it. The root cause is a change in how Superset 6.0.0rc1 assembles SQL for virtual datasets: calculated columns are no longer injected into the generated SQL as they were in 5.0, so the query just references the column name instead of the SQL expression. This logic lives in the SQLAlchemy connector code, not the ClickHouse engine spec, and affects how query columns are composed for virtual tables. No merged pull requests or migration notes directly address this, so it appears to be an unintentional regression in the generic SQL query assembly logic for virtual datasets, not a ClickHouse-specific change.

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other  Chat with Dosu Join Discord Share on X