On 03/07/14 13:54, Dimitry Sibiryakov wrote:
> 07.03.2014 10:44, Alex Peshkoff wrote:
>> Yes. That's one of the reasons. Among others is the fact that
>> IMessageMetadata may be returned from server after prepare, and at this
>> step we have no buffer: it will be allocated after receiving metainfo
>> based upon size of message from that info.
>     I also wonder why buffer is plain void* instead of IBuffer which could 
> perform
> translation of field index into pointer. Such class would save quite a few 
> mess in every
> place where now is written something like this: reinterpret_cast<int*>(buf +
> Msg->getOffset(i)).

Main reason is performance compromise. It's faster to store required 
information from IMessageMetadata somewhere in end-user code and use it 
to access data instead of calling dozens of virtual functions. For C++ 
there can be a lot of various wrappers (see for example 
firebird/Message.h). Probably one can invent similar helpers for other 
languages.

One more reasons to have plain buffer on my mind is use of API for 
writing various access components (like in Delphi). Component, working 
with IStatement, typically places rows received from server into set of 
row buffers. This helps to provide backscrolling, perform lookup 
operations, etc. It's obvious desire to make fetch() call to place 
returned data directly to the row buffer. With old SQLDA API it was 
necessary to change all pointers in SQLDA to achieve it. Currently one 
can just pass single pointer to next buffer to fetch() - and this job is 
done. Access to fields is usually performed by other layer of component. 
I have no idea how can IBuffer performing offset-to-pointer conversions 
help here.

>     Besides, it could allow to use any type of buffers, not only plain pool. 
> For example,
> in SQLDA interface it would save the allocation of buffer and moving data 
> from SQLDA into
> it and back.
>

Not sure it's possible for SQLDA where memory for fields allocated by 
user. Anyway, optimizing access from SQLDA interface is the last think I 
care about. In next version we will add namespaces, increase 
identifier's length - and that old monster will die silently. (Even 
today to access charset info one needs to get it from different fields 
for different data types!)


------------------------------------------------------------------------------
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works. 
Faster operations. Version large binaries.  Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

Reply via email to