feat: add an internal tryNext method
#2638
Conversation
The default cursor iteration behavior is to block until either a cursor is dead (has a cursor id of 0), or a non-empty batch is returned from the server for a `getMore` command. `tryNext` allows users to iterate a cursor optionally returning `null` if the `getMore` returns an empty batch (likely on a tailable + awaitData cursor). NODE-2917
mbroadst
force-pushed
the
NODE-2917/try-next
branch
from
077214a to
df05011
Compare
|
|
||
| next(cursor, callback); | ||
| if (cursor[kDocuments].length === 0 && blocking === false) { | ||
| return callback(undefined, null); |
There was a problem hiding this comment.
Is there a specific reason to use null over undefined? I suppose it makes more sense to communicate a non-existent object, so I'm not taking issue with it just wondering if there was some thinking behind it
Although maybe one reason to use undefined is so the result doesn't respond true to: typeof result === 'object'.
There was a problem hiding this comment.
I used null here for symmetry with our semantics around a "dead" cursor. When a cursor returns a zero cursor id, we return an explicit null to the user. I think this might have been left over from days when a Cursor inherited Readable since ending a stream is accomplished by readable.push(null), but either way the convention exists so I stuck with it
The default cursor iteration behavior is to block until either a cursor is dead (has a cursor id of 0), or a non-empty batch is returned from the server for a
getMorecommand.tryNextallows users to iterate a cursor optionally returningnullif thegetMorereturns an empty batch (likely on a tailable + awaitData cursor).NODE-2917