Support PreparedStatement stream parameters #208
Conversation
There was a problem hiding this comment.
Nit: ip-proto → iproto (in the commit message).
My main concern is that we can avoid materializing streams in memory. The API support is more important however, so if it is a significant amount of work, then skip it for now and file an issue re optimizatimizing this moment.
Also please consider UTF-8 / UTF-16 question.
nicktorwald
force-pushed
the
nicktorwald/gh-190-prepared-statement-stream
branch
2 times, most recently
from
f02c9b2 to
79db6a5
Compare
|
LGTM. Just several notes on wording. Re 'Revert changes made in d4d62e9' commit: It is better to do so using Re 'Support PreparedStatement stream parameters' commit: Typo: IPPROTO → iproto. I would not say that the protocol does not support streaming. At least if you know a size of your data you can calculate a packet size before encode it, send a packet header and then do a bunch of writes to a socket. When a size of data is known it is quite easy to calculate msgpack size. However you are right in the case when a size of data is not known: a client should materialize it or calculate a size of data somehow before start sending. I think it worth to formulate it more accurate in the commit message. |
Add capability to set streams as a parameter of ASCII or UNICODE text as well as SCALAR binary data. The input streams often are size unaware so it can be difficult to calculate the data size and, consequently, the iproto packet size. It leads the driver materializes the streams in proper data in advance and sends prepared the data as an ordinary text or raw bytes. Follow API is more important thing now than performance issues with streams. Closes: #190
This reverts commit d4d62e9. To be consistent with PreparedStatement.setUnicodeStream which provides UTF-8 encoding, ResultSet.getUnicodeStream has to also use the same encoding. Changes in d4d62e9 were made under the influence of JDBC API for getUnicodeStream that says 'a stream of two-byte 3 characters. The first byte is the high byte; the second byte is the low byte'.
nicktorwald
force-pushed
the
nicktorwald/gh-190-prepared-statement-stream
branch
from
79db6a5 to
2231ecf
Compare
|
Nice. It is okay. Let's proceed. |
Add capability to set streams as a parameter of ASCII or UNICODE text as
well as SCALAR binary data. Tarantool does not support a data streaming
via ip-proto so it leads the driver materializes the streams in proper
data in advance and sends prepared data as ordinary text or raw bytes.
Closes: #190