I"d use it as an excuse to dump BLR, or at least freeze and deprecate it. It serves no useful purpose and as you note, is an impediment to progress. It deserves to join slide rules, Beta Max, and four function calculators as footnotes in history books.
On 3/8/2016 8:02 AM, Dmitry Yemanov wrote: > All, > > The good thing is that the code internals are more or less ready to work > with context/stream number of any size, thanks to Claudio's refactoring. > So the issue is mostly about BLR. > > I see two possible solutions: > > 1) Bump BLR version, make all context-aware verbs to generate/parse > longer numbers (prefixed by counter, variable-length encoded, whatever) > if new BLR version is used. Support old BLR versions, for sure (for > migration, message descriptions, etc) but generate new BLR version for > new objects. > > The major problem here is backward compatibility. BLR version 6 cannot > be parsed by prior engines, so backward migration via gbak becomes > impossible (at least after some metadata have been modified in FB4). > > Perhaps we could hack gbak to change the first byte of the every BLR > stream (fix the BLR version to the older one) during restore, but the > context encoding is incompatible anyway. > > Maybe we could teach the engine to recreate BLR based on the existing > source code during restore, but (1) it gonna work only if restoring with > v4 gbak, (2) source code may be missing, (3) I don't really like how it > would affect the layering, (4) it gonna be slower. > > 2) Another solution is to keep BLR version 5 but introduce new versions > of existing context-aware verbs. They will be used only for context > numbers > 255. > > Very dumb, but simplifies backward migration. Only databases with high > context numbers (read: with metadata objects re-implemented under FB4) > will be impossible to migrate. > > I'm not sure whether we have enough BLR code space for that though. > > Can anyone think of any better idea? I have the former solution > implemented, but maybe we could do something more clever? > > > Dmitry > > ------------------------------------------------------------------------------ > Transform Data into Opportunity. > Accelerate data analysis in your applications with > Intel Data Analytics Acceleration Library. > Click to learn more. > http://makebettercode.com/inteldaal-eval > Firebird-Devel mailing list, web interface at > https://lists.sourceforge.net/lists/listinfo/firebird-devel ------------------------------------------------------------------------------ Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://makebettercode.com/inteldaal-eval Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
