On 11/10/18 12:12 PM, Mark Rotteveel wrote:
I do get the feeling (although I maybe wrong, as I don't think I fully understand the protocol), that this will be hard to implement,
Bot too hard. The most complex place is when we need to process segments inside segmented blobs (i.e. change endianness of segment size placed in the beginning of segment).
and it feels like the message structures need a lot of upfront knowledge of total message sizes
Upfront? May be we can say so... Message size and alignment is received from IMessageMetadata using standard API function, no dark magic here :) But certainy that should be done before processing batch.
which could be pretty memory intensive if considering blobs, and just a bit annoying for rows without blobs).
Except need to parse segments in segmented blob I see no problems here. What about memory consumption - on client it does not depend upon presence of blobs, all data is gathered into single stream and placed into same buffer. It's size 128 or 256Kb, i.e. not too big for 21 century :)
Couldn't this be more like a fetch (that is: streaming rows as individual messages)?
Rows should be treated as individual message at one step (when we talk about the wire) - when that message is converted into machine-neutral stream of bytes (i.e. XDR protocol). After it messages are once again gathered into the stream and buffered, first of all to minimize calls to network layer. How are they represented before XDR is implementation-specific thing, and certainly may be done in java client in some other way, not exactly like fbclient does.
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
