Repository navigation
Add LibSQL and Turso adapter - #13
Conversation
Wrapping each statement of a batch in its own observe() nests the timers, so every outer one contains all the inner ones. Measured against a real @libsql/client: a batch of six reported 2.39ms for a round trip that took 0.51ms, and the distortion grows with batch size — fifty statements would report about twenty-five times the truth. A batch loop is exactly where an N+1 hides, so that number has to be trustworthy. Drivers report no per-statement timing for a batch, so observeBatch() runs the round trip once and divides it evenly. Each statement's duration is an estimate; the sum, which is what a finding reports, is the measurement. Co-Authored-By: Claude Opus 5 <[email protected]>
|
Merged — thank you. Clean adapter, and the decision to record each I verified it against a real All correct. One thing that measurement turned up, which I fixed on merge rather than sending back: Monotonically increasing. The The nesting is genuinely clever and it preserves ordering and the return value correctly, which is why the tests pass. It is only the timing that suffers, and only for I added Also merged Shipping in 0.6.0 with a changelog credit. |
Closes #1
What changed
instrumentLibsql(client)through thenplusone/libsqlexport.execute()calls with positional or named arguments.batch()statement separately while preserving one driver call.Validation
npm test- 135 tests passingnpm run typechecknpm run lintnpm run buildnpm pack --dry-run@libsql/clientin-memory database