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
