fix: normalize key column name when CASESENSITIV is off#33
Draft
toddr-bot wants to merge 2 commits into
Draft
Conversation
When the key column is passed with mixed case (e.g. 'Produce_ID') and CASESENSITIV=0 (default), the key-field guard in STORE fails to match the lowercased field names from _fields(), allowing the key column to be included in INSERT/UPDATE statements. Tests verify: - STORE key-field guard fires with mixed-case key names - Record::CLEAR exclusion works with mixed-case key names Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
When CASESENSITIV=0 (the default), _fields() lowercases all stored
column names, but $self->{key} was stored as-is from the tie() call.
This caused the key-field guard in STORE to miss when the user passed
a mixed-case key name (e.g. 'Produce_ID'), allowing the key column
to be included in INSERT/UPDATE statements — potential data corruption.
Fix: lowercase $self->{key} at TIEHASH time when CASESENSITIV=0.
This ensures all downstream comparisons against $self->{key}
(STORE guard, Record::CLEAR exclusion, SQL WHERE clauses) are
consistent with the lowercased names from _fields().
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Normalize
$self->{key}to lowercase at TIEHASH time when CASESENSITIV=0 (the default).Why
_fields()lowercases stored column names when case-insensitive, but the key column name was stored as-is from thetie()call. When a mixed-case key name was used (e.g.Produce_ID), the key-field guard in STORE failed to match, allowing the key column into INSERT/UPDATE statements — potential data corruption.This also affected
Record::CLEAR, which builds a hash from the lowercased_fields()keys but tried to delete the original-case key name — a no-op that left the key column in the update set.How
One-line fix in TIEHASH:
$self->{key} = lc $self->{key} unless $self->{CASESENSITIV}. This ensures consistency with_fields()across all downstream comparisons and SQL generation.Complementary to PR #25 (field lookup normalization) — this PR fixes the key-side normalization that PR #25 doesn't address.
Testing
🤖 Generated with Claude Code
Quality Report
Changes: 2 files changed, 52 insertions(+), 1 deletion(-)
Code scan: clean
Tests: passed (OK)
Branch hygiene: clean
Generated by Kōan post-mission quality pipeline