On 06.04.2020 20:01, Leyne, Sean wrote:
Alex,
If we keep it, let's decide what new tables can be ignored when
restoring backwards and what ones are mandatory and thus should raise
an error. We may also consider going half-way and limiting the
backward restore to the one prior ODS version -- this will also simplifies
the code a lot.
We keep it, but only support backward restore to previous major ODS
version.
That approach would allow backward restore to any previous FB version,
although thru a cumbersome multiple restore path. If need to restore
from v4 to v2.5,
Sean, what benefits do you see in this restore method compared with more
tradiitional - backup v4 database using v4 server and v2.5 gbak, next restore
using 2.5 as usual?
I was referring to the ability to backup v4 database (ODS 13?), use v4 gbak to
restore to ODS 12 target (regardless of the FB version -- allowing for the
possibility that there could be a new FB version that doesn't require new ODS).
My point was that gbak should support restore to the previous ODS as much as
possible.
Consider that a future version introduces a single new feature like
"tablespaces" or table partitions, which obviously would require a new ODS.
Gbak for that version would need to ensure that a restore to the previous ODS is
supported.
An example of an exception is restoring DB with Packages *in use*, to an ODS
which doesn't support packages -- there is only so much that gbak should be
expected to support.
{Aside, the introduction of a non-backward compatible feature like Packages is
a prime reason why we should implement a feature (ASAP) to allow metadata
objects to be marked as Invalid. In that way, the restore would proceed but
the metadata would need to be 'fixed'}
Sean, as soon as the database contains new features not supported in
older versions one can not downgrade ODS version. Restore (by gbak) of
such database in a version which does not support actually used features
is just nonsense. That may be a separate task for a future to support
such downgrades, IMHO that should be not gbak-like tool, first thing to
be done is forget about any BLR codes from newer DB version. For gbak
that's close to rewriting it from scratch.
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
