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
