Firebird not experimental

[Alexander Thurgood]

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.
>
>