Skip to content

fix: Use singlestoredb dialect for sqlglot #36096

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
Vitor-Avila merged 1 commit into from
Nov 13, 2025
Merged

fix: Use singlestoredb dialect for sqlglot #36096

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 2 additions & 1 deletion superset/sql/parse.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -33,6 +33,7 @@
Dialect,
Dialects,
)
from sqlglot.dialects.singlestore import SingleStore
Copy link

@korbit-ai korbit-ai bot Nov 13, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unnecessary module-level import overhead category Performance

Tell me more
What is the issue?

The import of SingleStore dialect class is added at module level, which means it will be imported every time this module is loaded, even when SingleStore database is not being used.

Why this matters

This creates unnecessary import overhead for all users of this module, regardless of whether they actually use SingleStore databases. The import will add to module loading time and memory usage even for applications that never interact with SingleStore.

Suggested change ∙ Feature Preview

Consider using lazy importing by moving the import inside the code path where it's actually needed, or use a factory pattern that only imports the dialect when the specific engine is requested. For example:

def get_dialect(engine: str):
    if engine == "singlestoredb":
        from sqlglot.dialects.singlestore import SingleStore
        return SingleStore
    return SQLGLOT_DIALECTS.get(engine)
Provide feedback to improve future suggestions

Nice Catch Incorrect Not in Scope Not in coding standard Other

💬 Looking for more details? Reply to this comment to chat with Korbit.

Copy link
Contributor Author

@Vitor-Avila Vitor-Avila Nov 13, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unsure why, but the Singlestore dialect is not listed here (v27.15.2 is the current sqlglot pinned version in Superset), so we have to import the dialect directly. I checked the latest sqlglot version too but it's still the case.

from sqlglot.errors import ParseError
from sqlglot.optimizer.pushdown_predicates import (
pushdown_predicates,
Expand Down Expand Up @@ -101,7 +102,7 @@
"redshift": Dialects.REDSHIFT,
"risingwave": Dialects.RISINGWAVE,
"shillelagh": Dialects.SQLITE,
"singlestore": Dialects.MYSQL,
"singlestoredb": SingleStore,
Copy link

@korbit-ai korbit-ai bot Nov 13, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Missing backward compatibility for SingleStore engine name category Functionality

Tell me more
What is the issue?

The mapping key changed from 'singlestore' to 'singlestoredb' but there's no backward compatibility handling for existing configurations that may still use 'singlestore'.

Why this matters

Existing Superset installations with SingleStore databases configured using the 'singlestore' engine name will suddenly fail to parse SQL correctly, as they will fall back to the default 'base' dialect instead of the proper SingleStore dialect. This could cause SQL parsing errors and incorrect query behavior.

Suggested change ∙ Feature Preview

Add both mappings to maintain backward compatibility:

"singlestore": SingleStore,
"singlestoredb": SingleStore,

This ensures existing configurations continue to work while supporting the new naming convention.

Provide feedback to improve future suggestions

Nice Catch Incorrect Not in Scope Not in coding standard Other

💬 Looking for more details? Reply to this comment to chat with Korbit.

Copy link
Contributor Author

@Vitor-Avila Vitor-Avila Nov 13, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

singlestore was actually incorrect there, so the dialect was not being used and instead the default dialect was used for Singlestore.

"snowflake": Dialects.SNOWFLAKE,
# "solr": ???
"spark": Dialects.SPARK,
Expand Down
13 changes: 13 additions & 0 deletions tests/unit_tests/sql/parse_tests.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2803,6 +2803,19 @@ def test_kqlstatement_is_select(kql: str, expected: bool) -> None:
assert KustoKQLStatement(kql, "kustokql").is_select() == expected


def test_singlestore_engine_mapping():
"""
Test the `singlestoredb` dialect is properly used.
"""
sql = "SELECT COUNT(*) AS `COUNT(*)`"
statement = SQLStatement(sql, engine="singlestoredb")
assert statement.is_select()

# Should parse without errors
formatted = statement.format()
assert "COUNT(*)" in formatted


def test_remove_quotes() -> None:
"""
Test the `remove_quotes` helper function.
Expand Down
Loading