11.03.2014 15:21, Alex Peshkoff wrote: > On 03/11/14 17:39, Dimitry Sibiryakov wrote: >> IMHO, right way is to hide field order behind interface. > > Sorry, but field _order_ should better match order of output fields in > select for output messages and order of '?' parameters in input > messages.
Fields order != data order. Do anybody actually care that for Field 1 pointer to data must be < that pointer to data for Field 2? > It depends upon what data do you send/receive. For various numeric > formats data copying is just few asm commands. But the most important is > that most typical use of API (creating data access components) anyway > supposes placing data in some buffer of records. > And new APi is oriented first of all on making this operation as simple > as possible. Unfortunately, at the same time it makes any other using as hard as possible. Flexibility is lacked. >> You use undocumented > > Yes, documentation is not ready yet... > >> requirement to follow fb_utils::sqlTypeToDsc() behavior which is >> not optimal but compatible with old versions. It puts too tight restrictions >> on plugins >> and components authors. Keyword was "requirement", not "undocumented". > As I've already mentioned for people using c++ there are wrappers doing > exactly what you want. And that wrappers provide both excellent > performance and mentioned by you service when accessing data. What a > problem? You are wrong about wrappers' performance. Wrappers never make things simpler, they only (over-)complicate them. > In remote layer messages are really parsed field by field, but this is > not the only possible way to go. Our protocol traditionally provided > sending message buffers 'as is' between same architecture machines (not > less than 99% of data transfers). For this you can add method IBuffer::isKosher() to distinguish between data buffers that can be sent as is and those which requires to be copied into kosher (engine acceptable) buffers before using. > But if > sometimes we add data compression to remote - a method with sending > messages 'as is' can become actual once again. No. Current message buffers are uncompressed. You won't be able send it as is unless you add another requirement for users: provide the buffer in compressed format. But you can't do it without breaking backward compatibility. Dead end. > And please - do not forget about embedded access. As I already said: if engine can work with only one type of data buffer, it must take responsibility to convert any data buffer type into the suitable one, not to oblige everyone else to provide only "right" type. (As I already said, it will cause problems if you ever felt like to change this format to something better.) -- WBR, SD. ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
