Sorry for late answer - missed this letter on holidays

On 03/07/14 17:51, Dimitry Sibiryakov wrote:
> 07.03.2014 14:15, Alex Peshkoff wrote:
>> n 03/07/14 16:45, Dimitry Sibiryakov wrote:
>>>>      After prepare we get from server a metadata-only object. There is no 
>>>> need in offsets in
>>>> this object. Offsets are not a part of metadata at all, IMHO, and their 
>>>> presence in
>>>> IMessageMetadata is an architectural mistake.
>> You suggest to add a special roundtrip to get them?
>> I get_all_  metadata at once, and I do not understand why you call it
>> "architectural mistake".
>     You get not "all metadata". You get... errrr... "true metadata" and 
> offsets are not
> among them. Offsets are calculated later and whole code is based on hope that 
> two
> different pieces of code will calculate them in the same way. I.e. offsets are
> encapsulated into metadata and there is no way to keep them consistent with 
> real data. As
> the result, all Firebird developers have to be aware that different pieces of 
> code placed
> in different classes (and modules) are not independent and changing one of it 
> without
> appropriate changes in the counterpart will crash everything.
>     This is what I call "architectural mistake".

The fact that changing code in some place w/o appropriate changes in 
another can crash the whole thing is not something outstanding - try to 
pass NULL pointer somewhere where it's not expected and check for NULL 
is missing. I we call any such place "architectural mistake", than the 
whole libc is one big "architectural mistake". But usually it's called 
implementation detail :)

>
>     As the example: common/calsses/InternalMessageBuffer produces message 
> metadata from BLR
> using MetadataFromBlr(). After that remote/client/BlrFromMessage produces 
> _different_ BLR
> from input message metadata, but the rest of interface code works with 
> assumption, that
> new BLR is compatible with old buffer, created for old BLR.

Is it really incompatible? What specific format causes troubles? 
Certainly this should be fixed.

> BlrFromMessage just don't use
> offsets from input metadata.
>     If method MsgMetadata::makeOffsets is changed to group all null 
> indicators in the
> beginning of buffer (to save some space on alignments), whole remote module 
> will fail
> miserable.

If we collect all nulls in the beginning of the record not changing ODS, 
we will get unreadable databases. If we do it changing ODS, we have no 
problems. Same for data transfered over network - if we change protocol 
version when changing format of messages traveling between server and 
client - we have no problems.

>     You know, that encapsulation is one of basic things about OOP, right?..
>

Yes, but it's not related with how we provide metadata information to 
client.
Certainly, it's possible to transfer offsets in message over the wire 
together with the rest data in getInfo() call. But except ability to 
sort fields in record in arbitrary order (suppose more changes will be 
needed to make it work) we win nothing with that change.


------------------------------------------------------------------------------
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

Reply via email to