Follow-up from the #43 code review. The primary identifier-quoting fix (#43) makes the schema tree and lineage-graph vectors emit valid SQL for names like target_all.part-00000-…-c000.snappy.parquet``. Two deeper paths remain shallow and are tracked here.
1. Editor autocomplete can't match/qualify non-bare names
completions.js now quotes the candidate insert value, but completionContext (same file) still detects the typed word and the qualified parent using [A-Za-z0-9_] only:
- Mid-word splice: typing
part-00 leaves the caret in a word that starts after the - (word = 00); accepting splices the quoted name into the middle → part-`` part-…parquet` `` — invalid. (Pre-existing for dashed names; quoting doesn't fix it.)
- Lost qualified completion: after a backticked parent
`my-db`., the char before the . is a backtick, so parent='' and the table's column dropdown never appears.
A real fix teaches completionContext to recognize a backtick-quoted run as a single word/parent, and to match candidates whose label contains non-word chars.
2. qualify() is a dot-heuristic for MV-target / EXPLAIN-AST names
schema-graph.js qualify(db, name) decides "already db-qualified?" by name.includes('.'). For a dotted table name this misfires:
parseMvTarget won't match a backticked TO target → no writes edge.
parseAstTables tokens for dotted/backticked names are treated as already-qualified, so byId.has(sid) (keyed on raw db.name) misses → feeds/reads edges dropped.
So whole-DB/table lineage silently omits edges for exactly the dotted (parquet-import) tables that motivated #43. A depth-correct fix carries db separately out of parseMvTarget/parseAstTables (and strips backticks) instead of guessing from a dot.
3. (Optional) No chokepoint / guard for identifier quoting
Quoting is applied at ~8 call sites with no single constructor and no test/lint that flags a future raw '… FROM ' + name. Consider a guard test or a structural chokepoint so a new identifier→SQL site can't silently reintroduce the bug.
Context: #43 (the quoting fix), #41 (the lineage graph).
Follow-up from the #43 code review. The primary identifier-quoting fix (#43) makes the schema tree and lineage-graph vectors emit valid SQL for names like
target_all.part-00000-…-c000.snappy.parquet``. Two deeper paths remain shallow and are tracked here.1. Editor autocomplete can't match/qualify non-bare names
completions.jsnow quotes the candidateinsertvalue, butcompletionContext(same file) still detects the typed word and the qualifiedparentusing[A-Za-z0-9_]only:part-00leaves the caret in a word that starts after the-(word =00); accepting splices the quoted name into the middle →part-``part-…parquet` `` — invalid. (Pre-existing for dashed names; quoting doesn't fix it.)`my-db`., the char before the.is a backtick, soparent=''and the table's column dropdown never appears.A real fix teaches
completionContextto recognize a backtick-quoted run as a single word/parent, and to match candidates whoselabelcontains non-word chars.2.
qualify()is a dot-heuristic for MV-target / EXPLAIN-AST namesschema-graph.jsqualify(db, name)decides "already db-qualified?" byname.includes('.'). For a dotted table name this misfires:parseMvTargetwon't match a backtickedTOtarget → nowritesedge.parseAstTablestokens for dotted/backticked names are treated as already-qualified, sobyId.has(sid)(keyed on rawdb.name) misses →feeds/readsedges dropped.So whole-DB/table lineage silently omits edges for exactly the dotted (parquet-import) tables that motivated #43. A depth-correct fix carries
dbseparately out ofparseMvTarget/parseAstTables(and strips backticks) instead of guessing from a dot.3. (Optional) No chokepoint / guard for identifier quoting
Quoting is applied at ~8 call sites with no single constructor and no test/lint that flags a future raw
'… FROM ' + name. Consider a guard test or a structural chokepoint so a new identifier→SQL site can't silently reintroduce the bug.Context: #43 (the quoting fix), #41 (the lineage graph).