⚡ Bolt: optimize hot scanning loop and plan cache key generation

[cungminh2710]

Identified and implemented hot-path optimizations in the row-scanning logic of rain-orm.

Key Improvements:

• scanDirectRow: Replaced generic switch with prioritized if/else checks for reflect.Int64 (most common) and range-based checks for other integer types.
• newRowScanPlanForColumns: Fast-pathed single-column scans to bypass strings.Join overhead.
• Added documentation in .jules/bolt.md reflecting these codebase-specific patterns.

Impact:

• Measurable reduction in execution time for bulk scans and point lookups.
• Zero regression in functionality (all tests passing).
• Clean, documented code following existing library patterns.

---

PR created automatically by Jules for task 9236827995992481735 started by @cungminh2710

[google-labs-jules]

👋 Jules, reporting for duty! I'm here to lend a hand with this pull request.

When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down.

I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job!

For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with @jules. You can find this option in the Pull Request section of your global Jules UI settings. You can always switch back!

New to Jules? Learn more at jules.google/docs.

---

For security, I will only act on instructions from the user who triggered this task.

[greptile-apps]

Greptile Summary

This PR introduces two hot-path micro-optimizations in the row-scanning loop of rain-orm: fast-pathing reflect.Int64 (the most frequent database integer type) to skip an unnecessary overflow check, and avoiding strings.Join allocation for single-column cache key generation. It also adds a .jules/bolt.md learnings entry documenting the approach.

• scanDirectRow: switch on field.Kind() is replaced with a fast == check for Int64 followed by range comparisons for remaining integer types. The Int64 overflow-check skip is safe because v.Int64 is already int64 so OverflowInt would always return false.
• newRowScanPlanForColumns: A switch on len(cols) short-circuits the 0- and 1-element cases before calling strings.Join, eliminating a heap allocation on the common single-column code path.

Confidence Score: 4/5

Safe to merge; the optimizations are semantically equivalent to the original code and all edge cases are preserved.

The range-based Kind checks work correctly today and the Int64 overflow-skip is sound, but the code now silently assumes the numeric ordering of reflect.Kind constants — an assumption that is stable in practice but undocumented. A follow-up comment in the source would make the contract explicit and easier to audit on future Go upgrades.

pkg/rain/model.go — the two duplicated range-check blocks (value and pointer paths) both carry the same implicit Kind-ordering assumption and would benefit from a brief explanatory comment.

Important Files Changed

Filename	Overview
pkg/rain/model.go	Replaces switch statements with range checks on reflect.Kind values and adds a single-column fast-path for cache key generation; logic is semantically equivalent to original but relies on undocumented numeric ordering of Kind constants
.jules/bolt.md	Append-only documentation entry capturing the hot-loop and cache-key optimizations; no functional changes

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[scanDirectRow: col in int64ValueCols] --> B{kind == reflect.Int64?}
    B -- Yes --> C[field.SetInt - no overflow check needed]
    B -- No --> D{kind >= Int AND kind <= Int32?}
    D -- Yes --> E[OverflowInt check then SetInt]
    D -- No --> F{kind >= Uint AND kind <= Uint64?}
    F -- Yes --> G[negative + OverflowUint check then SetUint]
    F -- No --> H[assignRawValueToField fallback]

    I[newRowScanPlanForColumns] --> J{len cols}
    J -- 0 --> K[columnKey = empty string]
    J -- 1 --> L[columnKey = cols 0]
    J -- n > 1 --> M[strings.Join cols with NUL separator]
    K & L & M --> N[rowScanPlanKey lookup / insert]

Loading

Prompt To Fix All With AI

Fix the following 1 code review issue. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 1
pkg/rain/model.go:378-383
**Implicit reliance on `reflect.Kind` numeric ordering**

The range checks `kind >= reflect.Int && kind <= reflect.Int32` and `kind >= reflect.Uint && kind <= reflect.Uint64` are correct today (Int=2…Int32=5, Uint=7…Uint64=11 are contiguous and stable since Go 1), but this is an undocumented contract. If Go ever inserts a new Kind value inside one of those ranges, the branch would silently mismatch — e.g. a hypothetical `reflect.Int128` between 5 and 6 would fall into the Int32 branch and hit `SetInt` without an overflow check. A comment citing the specific iota values being relied upon (e.g. `// Int=2..Int32=5, Int64=6, Uint=7..Uint64=11`) would make the assumption self-documenting and easier to audit in future Go upgrades.

_{Reviews (1): Last reviewed commit: "⚡ Bolt: optimize hot scanning loop and p..." | Re-trigger Greptile}

[greptile-apps]

Implicit reliance on reflect.Kind numeric ordering

The range checks kind >= reflect.Int && kind <= reflect.Int32 and kind >= reflect.Uint && kind <= reflect.Uint64 are correct today (Int=2…Int32=5, Uint=7…Uint64=11 are contiguous and stable since Go 1), but this is an undocumented contract. If Go ever inserts a new Kind value inside one of those ranges, the branch would silently mismatch — e.g. a hypothetical reflect.Int128 between 5 and 6 would fall into the Int32 branch and hit SetInt without an overflow check. A comment citing the specific iota values being relied upon (e.g. // Int=2..Int32=5, Int64=6, Uint=7..Uint64=11) would make the assumption self-documenting and easier to audit in future Go upgrades.

Prompt To Fix With AI

This is a comment left during a code review.
Path: pkg/rain/model.go
Line: 378-383

Comment:
**Implicit reliance on `reflect.Kind` numeric ordering**

The range checks `kind >= reflect.Int && kind <= reflect.Int32` and `kind >= reflect.Uint && kind <= reflect.Uint64` are correct today (Int=2…Int32=5, Uint=7…Uint64=11 are contiguous and stable since Go 1), but this is an undocumented contract. If Go ever inserts a new Kind value inside one of those ranges, the branch would silently mismatch — e.g. a hypothetical `reflect.Int128` between 5 and 6 would fall into the Int32 branch and hit `SetInt` without an overflow check. A comment citing the specific iota values being relied upon (e.g. `// Int=2..Int32=5, Int64=6, Uint=7..Uint64=11`) would make the assumption self-documenting and easier to audit in future Go upgrades.

How can I resolve this? If you propose a fix, please make it concise.