On 27.08.2024 19:48, Robert Großkopf wrote:
Hi *,
Moreover
1) we still use FB 3.0.7 whereas 2 major releases have been published
(4 and 5) and version 6 is in dev.
At minimum, we should upgrade to version 5 to avoid trying to fix
bugs on a old FB version.
What would happen with all the old Firebid databases then? Might be a
good idea first to put to newest version and then to set non
experimental, but there are many people already using internal
Firebird and it should work without any problems when changing version
of LO (and changing Firebird-version this way).
IMO, the requirement to upgrade to FB 5 before moving it out of
experimental status is reasonable. Even though the change *should* be
backward-compatible (we keep the embedded DB in backup format, and it is
expected that backups of any older FB version are read by newer FB
versions, so the expectation is to have the older DB silently upgraded
to newer FB version), it won't be forward-compatible (older LO versions
will be unable to read ODBs created / upgraded by newer LO versions). So
minimizing this, having the upgrade in work
(https://gerrit.libreoffice.org/c/core/+/168449), is important to avoid
another bad impression of "the just-introduced functionality gets
incompatible (in one way) already in the next release".
On the other hand, it is OK to rely on this backward compatibility of
the experimental feature, and *not* require that "it should work without
any problems when changing version of LO" - when version changes from
newer to older (again, changing from older to newer is expected to work
automatically).
2) what about the existing odb with HSQL Embedded, should we propose
migration towards FB each time knowing there are still quite some
bugs about it?
I would prefer to add a special switch like "don't ask again". So old
HSQLDB still would exist
Note how Juan explicitly addressed that in the very first mail:
On 27.08.2024 0:06, Juan C. Sanz wrote:
HSQLDB Migration
According to TDF#116968
<https://bugs.documentfoundation.org/show_bug.cgi?id=116968>/(Database-Firebird-Migration)
- [META] Migrating existing embedded HSQLDB databases to
Firebird/,there do not seem to be any serious problems preventing its
use, but in any case, the migration process should not be automatic,
in my point of view. Very few databases offer a migration process from
one database to another, unless there is a commercial and/or economic
interest in doing so.
That is why the migration process should not be proposed in such an
invasive way when you open a HSQLDB database and at the same time you
are using Firebird (because you have activated the experimental
functions). This process could be associated to a wizard or an
independent menu option.
Proposal
In considering the above, I propose to the ESC (or whomever it may
concern):
*
...
*
Decouple HSQLDB migration from the existence or not of Firebird.
I totally agree, that the migration shouldn't be suggested at opening
*at all*, never; if the migration functionality is wanted kept at all
(which I personally doubt), then it should be some "tool" available in a
menu, for those who, for some reason, want and look for it. The end goal
of dropping HSQLDB from the package should be re-considered, and IMO
should not happen - just have it for compatibility, indefinitely (the
idea was to avoid Java dependency, but when there is an alternative of
FB, especially made the default, it's no more of a dependency than for
Java macros / extensions; and we have much more pressing Java dependency
in the report builder).
I support moving FB out of experimental ASAP (after FB5 upgrade). And
indeed, it is expected that we get more bug reports after that - it's
normal in any project, and especially so in our, with time-based releases.
--
Best regards,
Mike Kaganski
