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

Reply via email to