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
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
