Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 8743173c3a
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
sidemantic/adapters/thoughtspot.py
Outdated
| sql = "SELECT * FROM " + clauses[0] | ||
| for clause in clauses[1:]: | ||
| sql += f"\n{clause}" | ||
|
|
||
| return sql, None |
There was a problem hiding this comment.
When a worksheet has joins (len(clauses) > 1), _build_join_sql returns (sql, None), which drops the base table name. _parse_worksheet relies on this return value to set _worksheet_base_table, and _export_worksheet falls back to model.name when it’s missing. This means a parse→export round-trip for any joined worksheet will emit TML that uses the worksheet name as the base table (and in join on expressions), producing invalid table references. Returning the actual base_table alongside the SQL avoids corrupting exports for multi-table worksheets.
Useful? React with 👍 / 👎.
sidemantic/adapters/thoughtspot.py
Outdated
| for rel in model.relationships: | ||
| tables.append({"name": rel.name}) | ||
| join_name = f"{base_table}_{rel.name}" | ||
| join_type = "LEFT_OUTER" if rel.type in {"many_to_one", "one_to_one"} else "OUTER" | ||
| on_expr = f"[{base_table}::{rel.sql_expr}] = [{rel.name}::{rel.related_key}]" |
There was a problem hiding this comment.
_export_worksheet always builds join predicates as [base_table::{rel.sql_expr}] = [{rel.name}::{rel.related_key}], which assumes the foreign key lives on the base table. For one_to_many relationships, the foreign key is on the related model (per Relationship semantics used elsewhere in the codebase), so this expression is inverted (e.g., [customers::customer_id] = [orders::id] instead of [customers::id] = [orders::customer_id]). Exporting a model with one_to_many relationships (e.g., from LookML or Omni) will therefore generate incorrect joins in ThoughtSpot TML.
Useful? React with 👍 / 👎.
1 participant
Adds ThoughtSpot TML table/worksheet support with relationship inference and auto-detection. Includes comprehensive synthetic fixtures and parsing/export/roundtrip tests. Tests: uv run pytest tests/adapters/thoughtspot -v.