akashchamp opened a new pull request, #44583:
URL: https://github.com/apache/superset/pull/44583
### SUMMARY
Charts built on a MongoDB dataset with a `schema` set return no rows.
`SqlaTable.get_sqla_table` builds `table(self.table_name, schema=self.schema)`,
so the chart query renders `FROM "testdb"."orders"`. PyMongoSQL treats the
whole `FROM` reference as a single, literal collection name rather than parsing
`schema.table`, so it looks for a collection named `testdb.orders` and finds
nothing.
#44141 fixed the same rendering for SQL Lab (Data Preview and the schema
selector) by having `select_star` route through
`MongoDBEngineSpec.quote_table`, which emits only the bare, quoted collection
name and relies on `adjust_engine_params` to select the schema at the
connection level instead. Datasets/charts don't go through `select_star`, so
they kept building a schema-qualified identifier directly and were left broken.
This PR:
- Adds a `BaseEngineSpec.quote_table_includes_schema` capability flag
(default `True`, matching every engine's existing behavior).
- Sets `quote_table_includes_schema = False` on `MongoDBEngineSpec`,
alongside its existing `quote_table` override.
- Makes `SqlaTable.get_sqla_table()` consult the flag: when `False`, it
builds the FROM-clause identifier through the engine spec's own `quote_table`
(the same call `select_star` already makes), instead of the default
`table(name, schema=schema)`. Engines that don't set the flag are unaffected.
### BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF
Backend-only fix to SQL generation; no UI change. See TESTING INSTRUCTIONS
for the query text before/after.
### TESTING INSTRUCTIONS
1. `docker run -d --rm -p 27017:27017 mongo:7` and seed documents into
`testdb.orders`.
2. Add a database with `mongodb://localhost:27017/testdb?mode=superset`.
3. Create a dataset on `testdb` / `orders` and build any chart on it.
4. Before this change: the chart returns no data; the generated SQL has
`FROM "testdb"."orders"`.
5. After this change: the chart returns rows; the generated SQL has `FROM
orders`, and the `testdb` schema is applied via the MongoDB connection's
`database` connect argument (through `adjust_engine_params`, unchanged from
#44141).
Manually verified end-to-end against a real, isolated `mongod` instance
(v8.0.6) seeded with 3 documents in a `testdb.orders` collection, through the
actual `Database`/`SqlaTable`/PyMongoSQL stack (no mocks):
- `SqlaTable(table_name="orders", schema="testdb").get_sqla_table()`
compiled to `SELECT * FROM orders`, executed against the seeded instance, and
returned all 3 rows.
- The pre-fix table construction (`table("orders", schema="testdb")`, what
`get_sqla_table` built before this change) compiled to `SELECT * FROM
testdb.orders` and, executed against the same instance, returned 0 rows —
reproducing the reported bug from current `master`.
Automated tests:
- `pytest tests/unit_tests/db_engine_specs/test_mongodb.py
tests/unit_tests/connectors/sqla/models_test.py` — 134 passed.
- `ruff check` / `ruff format --check` on the changed files — clean.
- `pre-commit run --files <changed files>` — all hooks passed (mypy, pylint,
ruff, db-engine-spec-metadata validation, etc).
New regression tests:
- `test_get_sqla_table_does_not_qualify_collection` (`test_mongodb.py`) —
asserts `MongoDBEngineSpec.quote_table_includes_schema is False` and that a
dataset's `get_sqla_table()` compiles to an unqualified `FROM orders`.
- `test_get_sqla_table_schema_not_qualified_when_engine_opts_out` /
`test_get_sqla_table_schema_qualified_by_default` (`models_test.py`) — cover
both branches of the new flag generically, independent of MongoDB.
### ADDITIONAL INFORMATION
- [x] Has associated issue: Fixes #44576
- [ ] Required feature flags:
- [ ] Changes UI
- [ ] Includes DB Migration
- [ ] Introduces new feature or API
- [ ] Removes existing feature or API
This PR was prepared with AI assistance (Claude Code). The diff, automated
test run, and the end-to-end manual verification described above were all
reviewed before submission.
--
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]