SchemaGate 0.1.42 adds dimension-aware retrieval for harder text-to-SQL questions

SchemaGate shipped version 0.1.42 on September 12, adding a dimension-aware coverage step to its identity-scoped schema selector and changing its SQL-generation path to better support complex, multi-table questions. The tagged update contains four commits beyond v0.1.41; PyPI lists the package as alpha software. (GitHub compare, PyPI metadata)

What changed

The new selector derives “dimensions” from the schema’s join graph: when two or more objects reference the same object, SchemaGate can treat that object as a likely dimension or lookup table. It then prefers that table when it covers the same concept as a higher-scoring but less useful candidate. The project says the logic works with declared and inferred relationships and is implemented in both its Python library and browser-based JavaScript selector. (dimension-selection commit)

That matters for questions that ask for a measure plus a descriptive attribute, such as a tenant name. A flat similarity ranking can retrieve the fact or dashboard object containing the measure but omit the lookup table needed to resolve the requested label. The author reports that, on four questions against a 1,245-object live schema, refusals fell from 35% in the baseline to zero after inferred joins and dimension coverage were enabled. Those figures are project-reported, from a small private workload rather than an independent benchmark. (dimension-selection commit)

The release also rewrites prompt language that had told the model to produce “one SELECT statement.” According to the implementation note, the model sometimes interpreted that as a one-table restriction even when join tables were present. The new wording explicitly allows CTEs, window functions and five-table joins within one statement, raises the generation budget from 500 to 2,000 tokens, and distinguishes the scalar REPLACE() function from write statements such as REPLACE INTO. (complex-SQL commit)

The deployment takeaway

SchemaGate’s broader design filters the schema by caller identity before assembling the model prompt, then retrieves a small set of candidate objects with BM25, vector similarity and foreign-key expansion. Its public demo uses invented schemas and makes no model or database call; the repository says restricted tables are omitted from the prompt rather than merely ranked lower. (project README, browser demo)

For practitioners, v0.1.42 is a useful reminder that schema retrieval is not just search. It must preserve the structural tables needed to answer the question, pass their relationships clearly to the generator and keep authorization ahead of retrieval. The release is still alpha and its live-schema results are self-reported, so teams should replay their own executed-query suite before adopting the new ranking behavior. (PyPI metadata, GitHub compare)