Hi all,
+1 to everything Mike wrote, with one further observation:
- the embedded HSQLDB is platform agnostic which means that one can
share it across OSes, and to the extent that a JDK is available, is
readable on all of the main platforms for which a LO release is
available (and even some for which LO doesn't provide release packages,
e.g. the BSDs).
My understanding was that the same is not guaranteed for embedded FB due
to the endian-(n/m)ess of the architectures.
Does the use of the backup format take this into account? In other
words, if I prepare an embedded FB ODB file on macOS Arm and send it to
someone on Windows x86_64, will it be readable/exploitable/modifiable ?
Obviously, I'm thinking here of the somewhat "old" way of distributing
"single" file databases for use/re-use by other people with different
hardware/OS setups. How prevalent this might still be today, I have no
idea, but in a corporate setting might be fairly common.
Alex
Le 28/08/2024 à 10:47, Mike Kaganski a écrit :
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.
