converters/orionbelt/tests/fixtures/tpcds_ossie.yaml declares a field on the date_dim dataset
that TPC-DS does not have:
205: - name: d_month_name
209: expression: d_month_name
The real columns are d_moy (month of year), d_month_seq, and d_current_month. There is no
month-name column in the TPC-DS schema at all.
Reproduction
Any DuckDB, no extra tooling:
INSTALL tpcds; LOAD tpcds;
CALL dsdgen(sf = 0.01);
SELECT column_name FROM duckdb_columns()
WHERE table_name = 'date_dim' AND column_name ILIKE '%mo%';
┌─────────────────┐
│ column_name │
├─────────────────┤
│ d_month_seq │
│ d_moy │
│ d_current_month │
└─────────────────┘
No d_month_name. Anything that resolves that field against a real TPC-DS table fails; in our case:
Binder Error: Referenced column "d_month_name" not found in FROM clause!
Candidate bindings: "d_month_seq"
How it was found
We build a DuckDB implementation that executes Ossie models rather than converting them, so we can
run every metric against every dimension and diff the results against hand-written TPC-DS SQL. Doing
that at sf=1 surfaced it. Our own fixtures had inherited the same mistake from the same source and
are now corrected to d_moy; yours is left untouched since it is your file.
Why it survives in a converter test suite
Nothing in a conversion round-trip touches the physical table, so a field naming a column that does
not exist converts perfectly and never fails. It only shows up when something tries to run a query
that groups by it.
That is not a criticism of the fixture so much as an observation that execution catches a class of
error conversion cannot — which may be worth keeping in mind for the compliance/ suite.
Suggested fix is a one-line rename to d_moy, or dropping the field. Happy to send the PR.
(Edited to correct the file path: this was tpcds_osi.yaml when I first looked and has since been
renamed. Re-verified against main today; the field is still there at lines 205 and 209.)
converters/orionbelt/tests/fixtures/tpcds_ossie.yamldeclares a field on thedate_dimdatasetthat TPC-DS does not have:
The real columns are
d_moy(month of year),d_month_seq, andd_current_month. There is nomonth-name column in the TPC-DS schema at all.
Reproduction
Any DuckDB, no extra tooling:
No
d_month_name. Anything that resolves that field against a real TPC-DS table fails; in our case:How it was found
We build a DuckDB implementation that executes Ossie models rather than converting them, so we can
run every metric against every dimension and diff the results against hand-written TPC-DS SQL. Doing
that at
sf=1surfaced it. Our own fixtures had inherited the same mistake from the same source andare now corrected to
d_moy; yours is left untouched since it is your file.Why it survives in a converter test suite
Nothing in a conversion round-trip touches the physical table, so a field naming a column that does
not exist converts perfectly and never fails. It only shows up when something tries to run a query
that groups by it.
That is not a criticism of the fixture so much as an observation that execution catches a class of
error conversion cannot — which may be worth keeping in mind for the
compliance/suite.Suggested fix is a one-line rename to
d_moy, or dropping the field. Happy to send the PR.(Edited to correct the file path: this was
tpcds_osi.yamlwhen I first looked and has since beenrenamed. Re-verified against
maintoday; the field is still there at lines 205 and 209.)