Javascript driver makes irritating assumptions about batched streams

[mlucy]

Currently, the javascript driver assumes that if it gets back SUCCESS_PARTIAL, there is more data to be read. That is, it can't handle a SUCCESS_PARTIAL followed by an empty SUCCESS_STREAM.

The server currently supports this assumption by holding on to at least one piece of data before sending back SUCCESS_PARTIAL. It would be nice if we didn't have to do this.

[neumino]

If I'm not mistaken, the reason why the server has ton compute one piece of data before sending SUCCESS_PARTIAL is because of hasNext.

Are you suggesting that hasNext should be more javascript-like -- that is to say asynchronous?
(or get rid of it?)

[mlucy]

The javascript driver can hold on to the one result rather than expecting the server to. It doesn't give the user the last result of a SUCCESS_PARTIAL until it has the next response from the server.

[srh]

Note that it should be a different protocol buffer command that implements these new semantics -- the existing one that gets these SUCCESS_PARTIAL and SUCCESS_STREAM responses should be marked obsolete but still supported for now to save our users some pain when upgrading.

[coffeemug]

Assigning to @Tryneus.

[Tryneus]

I have a fix up for the js driver in review 1001. This also includes a change for the server to no longer ensure that SUCCESS_SEQUENCE contains at least one row (this simplifies the logic in stream_cache2_t significantly).

[Tryneus]

This has been approved and merged into next in commits 56d5d6b and d0b6521. Will be in release 1.11.