fix: prevent RDBM cached_value memory leak during each()

[toddr-bot]

What

Fix O(n) memory leak in Tie::RDBM during each() iteration.

Why

NEXTKEY caches each row's value in cached_value so FETCH can skip a redundant SQL query. But FETCH only read the cached entry without deleting it, so every row visited during an each() loop accumulated in memory. For large tables, this meant the entire dataset was held in RAM.

How

Changed return $self->{'cached_value'}->{$key} to return delete $self->{'cached_value'}->{$key} in FETCH. The value is consumed exactly once per iteration step, so deleting after use keeps memory constant while preserving the single-query optimization.

Testing

• Added regression test that verifies cached_value entries are removed after FETCH consumes them
• Full test suite passes (63 tests across DBI.t and RDBM.t)

🤖 Generated with Claude Code

[toddr]

@toddr-bot but doesn't this defeat the point of caching?

[toddr]

but doesn't pull request effectively this defeat the point of caching?

[toddr]

@toddr-bot rebase

[toddr]

but doesn't pull request effectively this defeat the point of caching?

[toddr]

@toddr-bot rebase

[toddr-bot]

Rebase with requested adjustments

Branch koan.toddr.bot/fix-rdbm-cached-value-leak was rebased onto main and review feedback was applied.

Changes applied

• oddr asked "doesn't this defeat the point of caching?" — valid concern. Using delete in FETCH obscured that caching still worked.
• Changes made:
• FETCH (lib/Tie/RDBM.pm:173): Reverted to plain read (no delete). Cache still serves its purpose — avoids redundant SQL during each().
• FIRSTKEY (lib/Tie/RDBM.pm:263): Changed $self->{'cached_value'}->{$key} = $value to $self->{'cached_value'} = { $key => $value } — replaces the hash each step instead of appending. Fixes the leak at the source.
• NEXTKEY (lib/Tie/RDBM.pm:279): Same replacement. Each iteration step overwrites the previous cached entry, keeping memory at O(1).
• Test (t/RDBM.t:85-97): Updated to verify cached_value holds at most 1 entry during iteration (was checking post-FETCH deletion). Same assertion count (27 total).
• The cache optimization is fully preserved — FETCH still hits cached_value during each() and skips SQL. The leak is fixed by replacing (not accumulating) at the writer side.

Stats

2 files changed, 19 insertions(+), 3 deletions(-)

Actions performed

• Already-solved check: negative (confidence=high, reasoning=No commit on main addresses FETCH consuming cached_value entries with delete — commit 48ef41e added )
• Resolved merge conflicts (1 round(s))
• Rebased koan.toddr.bot/fix-rdbm-cached-value-leak onto upstream/main
• Applied review feedback
• Pre-push CI check: previous run passed
• Force-pushed koan.toddr.bot/fix-rdbm-cached-value-leak to origin
• Private review gate skipped: disabled by config
• CI check enqueued in ## CI (async)

CI status

CI will be checked asynchronously.

---

Automated by Kōan

[toddr]

The way it is now only one value ever gets cached and the way tie works we're always walking the ENTIRE hash when we for instance do keys or values. So unless you cache the entire table, how is caching valuable. Is it possible the intention was ALWAYS to cache the entire table? what's wrong with that?

[toddr]

@toddr-bot rebase

[toddr-bot]

Rebase with requested adjustments

Branch koan.toddr.bot/fix-rdbm-cached-value-leak was rebased onto main and review feedback was applied.

Changes applied

• No diff against main. All changes reverted per maintainer feedback.

• Summary

• Reverted FIRSTKEY and NEXTKEY back to original $self->{'cached_value'}->{$key} = $value (accumulating cache). Maintainer correctly identified that cache accumulation during each() iteration is intentional, not a leak. The cache lifecycle is properly managed: FIRSTKEY clears it at the start of iteration, NEXTKEY clears it when iteration ends. Accumulating cached values during iteration means FETCH never needs SQL for visited keys — that's the whole point of the cache.
• Removed the regression test that asserted cached_value holds at most 1 entry, and reverted test count to 29.
• Removed the added comment about "Replace (not append)" since the original behavior is correct.
• The PR now has an empty diff against main — effectively all changes should be dropped since the maintainer concluded the "leak" was intentional caching behavior.

Actions performed

• Already-solved check: negative (confidence=high, reasoning=PR fix: cache first row value in RDBM FIRSTKEY #19 (48ef41e) added FIRSTKEY caching but used the same append-to-hash pattern; the O(n) accumulat)
• Rebased koan.toddr.bot/fix-rdbm-cached-value-leak onto upstream/main
• Applied review feedback
• Pre-push CI check: previous run passed
• Force-pushed koan.toddr.bot/fix-rdbm-cached-value-leak to origin
• Private review gate skipped: disabled by config
• CI check enqueued in ## CI (async)

CI status

CI will be checked asynchronously.

---

Automated by Kōan