Abdulrehman-PIAIC80387 commented on code in PR #42463:
URL: https://github.com/apache/superset/pull/42463#discussion_r3680743883
##########
superset/connectors/sqla/utils.py:
##########
@@ -109,13 +110,13 @@ def get_virtual_table_metadata(dataset: SqlaTable) ->
list[ResultSetColumnType]:
dataset.sql, **dataset.template_params_dict
)
except SupersetSyntaxErrorException as ex:
- raise SupersetGenericDBErrorException(
+ raise SupersetVirtualTableParseException(
message=_("Template processing error: %(error)s", error=str(ex)),
) from ex
try:
parsed_script = SQLScript(sql, engine=db_engine_spec.engine)
except SupersetParseError as ex:
- raise SupersetGenericDBErrorException(
+ raise SupersetVirtualTableParseException(
message=_("Invalid SQL: %(error)s", error=ex.error.message),
) from ex
Review Comment:
Fixed in `a5d642b`. Correct — `SupersetParseError` fires on any invalid SQL,
including static SQL with no template dependency.
Now checking whether the input SQL contained Jinja markers (`{%` or `{{`) at
the catch. An "Invalid SQL" outcome on Jinja input is very likely a rendering
artifact (empty `filter_values('col')` → `WHERE col IN ()`), so it raises the
soften-able `SupersetVirtualTableParseException`. Static invalid SQL (no Jinja
markers) keeps raising the base `SupersetGenericDBErrorException` and
hard-errors as before — the pre-existing
`test_get_virtual_table_metadata_invalid_sql` covers that as a regression guard.
Also added `test_get_virtual_table_metadata_jinja_parse_error_is_softened`
to lock in the Jinja-render-produces-invalid-SQL case.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
