Add support for iterators and/or generators about better-sqlite3 HOT 5 CLOSED

This could be done. The only safe way of doing it would be to lock the database object upon creating an iterator, and unlocking the database object upon closing the iterator. As an example, trying to do any database operation inside the each() callback currently results in a TypeError. This would have to follow the same rules. Regardless, I can see the benefits of it.

Don't worry about opening a PR (although I accept PRs), I'm happy to implement this myself

from better-sqlite3.

This is next on my to-do list.

from better-sqlite3.

The Statement#iterate() method is now supported as of v4.0.1.

from better-sqlite3.

Wow, did the iterate() version cause that much of a performance boost (3.2x to 28.2x) ?

Is that only due to the fact we don't have to allocate an array ?

Well anyways, that's really awesome.

from better-sqlite3.

Wow, did the iterate() version cause that much of a performance boost (3.2x to 28.2x) ?

No, it's misleading, I apologize.

The old benchmark tested how well each library was able to read every row of a query in sequence, without interruptions. The new benchmark tests the same thing but with the possibility of interruptions. Iterators handle this very well, node-sqlite3 does not.

Essentially, since iterate() is much more powerful than each(), I felt it would be useful to benchmark what the equivalent power would cost in node-sqlite3. As it turns out, trying to replicate iterate() in node-sqlite3 is extremely costly (28.2x more costly).

If you're iterating over every row of a query without interruptions or early termination (break/return/throw), using all() will still be slightly faster than iterate().

 for (var row of stmt.all()) { ... } // faster
 for (var row of stmt.iterate()) { ... } // slightly slower, but more flexible

from better-sqlite3.