Crate improv_data_source 

Shared “data source” bookkeeping for Improv’s import/export backends (improv_storage_sql, improv_storage_csv, and future formats).

Post-v0.5.0 Phase D: improv_storage_sql::import_query and improv_storage_csv::import_csv_from independently reinvented the same ~40-line block — ensure the mapped categories exist, create the input measure, intern dimension values into item ids (reusing existing items by name on re-import), then register the interned items on the model. That block is genuinely format-agnostic: it only touches CategoryId + MeasureId + names, never a source-specific column reference or row type. This crate extracts it so a third tabular format (Parquet, JSON-lines, …) reuses it instead of copying it a third time.

What deliberately did NOT move: ImportSpec/DimensionMapping in each backend keep their own shape (SQL’s column is a plain query-result name plus a refresh_policy; CSV’s is a name-or-index ColumnRef plus a value_type) — unifying those would touch the backends’ public field types, which ripples into improv_cli’s call sites (out of scope, and not worth it: the two shapes differ for real reasons, not by accident). There is also no shared DataSource trait: SQL’s source is an open connection, CSV’s is a path/reader, and nothing in the workspace calls either backend generically — a trait with no generic caller is indirection, not reuse.

Structs

ItemInterner

Per-category name -> ItemId interner used while importing rows: dimension values are looked up (reusing an existing item of that name) or minted a fresh sequential id. Seed from the model’s current items so re-import / refresh reuses items instead of creating duplicates with the same name.

Functions

add_input_measure

Create (or overwrite) the input measure an import populates.

ensure_categories

Ensure a category exists for each (id, name) pair. Idempotent: an existing category (e.g. from a prior import) is left untouched.