Repository navigation
Raise PrimaryKeyError instead of ValueError for primary key issues #16
Description
Currently, a ValueError is raised when issues with the primary key are encountered. These issues are:
- the primary key property not holding for the data
- the specified columns not being present
- an empty primary key being provided
- no primary key at all.
A dedicated PrimaryKeyError would allow catching these issues specifically, instead of relying on the broad ValueError.
Activity
MariusMerkleQC commentedon Mar 16, 2026
Thanks for the suggestion! Could you share more about your use case? In particular, are there situations where you'd want to catch primary key errors programmatically rather than fixing the data or the key specification?
NilsSeibertQC commentedon Mar 19, 2026
Of course, here are some more details: We programatically create comparison reports for many frames. We have a schema and thereby primary key assumption for each. But in case of recent schema changes, this assumption might not reflect the actual data. We want to include such
PrimaryKeyErrors as information in the report, but want to fail on other errors. Validating our primary key assumption before using diffly duplicates work, which we would like to avoid.MariusMerkleQC commentedon Mar 19, 2026
Thanks for sharing. I can understand why a dedicated
PrimaryKeyErrorsimplifies your workflow. EgeKaraismailogluQC and I also discussed that we're in favor of adding it as it improves readability, so I introduced it in #17.NilsSeibertQC commentedon Mar 19, 2026
Thanks!
MariusMerkleQC commentedon Mar 19, 2026
Note that we decided to raise a
ValueErrorfor this case, as it's an issue with the schema rather than the primary key.NilsSeibertQC commentedon Mar 19, 2026
Thanks for implementing, looks good. I understand the decision to raise
ValueErroron primary key columns not being present. Checking column existence beforehand is not much work.