nodejs / nodejs/node

sqlite: remove the null prototype from result rows

Open
#65,799 4 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
JavaScript
Stars
122k
Forks
37.3k
Avg merge
4d 2h
Merged PRs (30d)
283

Description

Current behavior

Rows returned by get(), all() and iterate() are created with a null prototype. The V8 API that does this produces dictionary-mode objects, and V8 will not cache a prototype transition on a dictionary map, so every row also gets its own freshly allocated hidden class. Rows from the same statement therefore share no shape: they are slow to build, and every property access on them in user code is megamorphic.

Proposal

Drop the null prototype and build rows with v8::DictionaryTemplate, cached per statement. Rows become ordinary objects, and every row of a statement shares one hidden class.

Pros

  • all() is 10–37% faster depending on the query; reading the rows afterwards is far cheaper still.
  • Consistent with run(), which already returns an ordinary object, and with better-sqlite3.

Cons

  • Semver-major.
  • Rows can no longer be indexed by untrusted keys without Object.hasOwn()row.toString and row.constructor start resolving through Object.prototype.
  • User code comparing rows against { __proto__: null, ... } breaks.

Prototype pollution is not a concern either way: rows are built by defining own properties directly, so a __proto__ column is an own property and never reaches Object.prototype.

I have benchmarks and a working implementation if there is interest.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by locating the implementations of get(), all(), iterate(), and the existing run() result handling, then read how the V8 API and v8::DictionaryTemplate are used. Review the proposed benchmarks and working implementation mentioned in the issue. Done means evaluating the ordinary-object behavior, shared row shape, performance, and semver-major compatibility concerns.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript, sqlite
Domain
backend, databases
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.