CSV import currently does case-sensitive column matching. If an imported CSV has EmailAddress and the existing table has emailAddress (or email_address), the import treats it as a new column instead of matching the existing one. This is friction for users importing CSVs from external sources that don't match Harper's exact column casing.
Ask
Detect case-only (and possibly camel↔snake) differences during CSV import, and match against the existing column rather than creating a new one.
Design considerations
- Default behavior: case-insensitive match. Optional flag (e.g.
caseSensitiveColumns: true) to opt out.
- Ambiguity: if a CSV has both
name and Name columns AND the table has only name, what wins? Reject the import with a clear error rather than picking arbitrarily.
- Snake_case ↔ camelCase: out-of-scope for this ticket unless trivial — opening a second ticket if asked.
Acceptance criteria
- Case-only mismatch between CSV column and existing attribute uses the existing attribute.
- Ambiguous cases (two CSV columns map to the same attribute) are rejected with a clear error.
- Tests cover: exact match, case-only mismatch, ambiguous mismatch.
🤖 Filed by Claude on behalf of Kris.
CSV import currently does case-sensitive column matching. If an imported CSV has
EmailAddressand the existing table hasemailAddress(oremail_address), the import treats it as a new column instead of matching the existing one. This is friction for users importing CSVs from external sources that don't match Harper's exact column casing.Ask
Detect case-only (and possibly camel↔snake) differences during CSV import, and match against the existing column rather than creating a new one.
Design considerations
caseSensitiveColumns: true) to opt out.nameandNamecolumns AND the table has onlyname, what wins? Reject the import with a clear error rather than picking arbitrarily.Acceptance criteria
🤖 Filed by Claude on behalf of Kris.