--- Comment #15 from Florian Reisinger <> ---
"It is up to developer to decide what is best" (non 100% quote from the linked
thread) is not always the best solution as backward compatibility takes effort.

As I am doing my master thesis "done correctly" is a very hard term in software
engineering. Ignoring that...

"In the current state, the old HSQLDB data is also kept in the odb file 
after migration. You can revert the migration by unzipping the odb 
file and overwriting the URL in content.xml in tag 

Besides that, the migration will be permanent only if you save the 
document and a red circle on the save button indicates that something 
has been changed."

For how long is it planned that all data is duplicated inside the ODB file?
That's the user-unfriendly way to copy the ODB file and convert the copy.

I do not see a big discussion about the change in DB (or I was not aware of
that). I do not say we should not move to a new database, but I (even as a
developer) do not expect in END USER software to change the file format in an
incompatible way. The current changes feels like having a DOCX file in a DOC
file without viability from outside!

Moreover for people, which are not reading the mailing lists issuing a
deprication notice at least in the release before it will be removed is
necessary. I do not say that we need a perfect convertation tool or a perfect
Firebird driver. However, with so few time for feedback (especially from very
complex DBs) we won't get feedback in time.

Even Robert's DBs from the handbook are not working at the moment.

The user gain time to test the changes and adapt for migration. For end user
facing software it is important to keep the format stable. Therefore switching
from an HSQLDB from 2005 to an up to date one would be as problematic as the
change to firebird.
I do not see parallels with MySQL (or HSQLDB for that purpose) as it can be
expected from developers that such a migration is tested. This care, however,
cannot be expected from end users (which Robert and I try to protect).

Such a transition will always be painful, However doing this in a big-bang
style like this - without urgent need to remove the old DB is not
comprehend-able for me. If you care to explain why

- removing a DB backend without deprication notice
- keeping the HSQLDB data in the ODB file WITHOUT possibility to open it with
an old version of LibreOffice
- hushing the transition to the new database backend

is a good idea.

The next bit is IMHO:

- Putting it in the 6.0 release notes is impossible - already released.
  --> Mark it for removal in 6.1 with removal in 6.2 / 6.3
    --> Would give us time to fix corner case bugs
  --> New databases will be created with Firebird (by default?) in 6.1
- Why keep the old data in the file?
  --> Creating a new file with just Firebird data makes more sense as the end
user is not able to recover the data!
- Why do we need to get rid of HSQLDB so quickly?
  --> Is it the last piece of Java code?
  --> Does it solve lots of problems?
    --> From Robert's tests it seems that Firebird has some problems
- In the linked thread some typed are declared different in HSQLDB and Firebird
  --> Is it tested that transition even works for these types (even if the data
size only COULD be too large but isn't at the moment.
- Do we have a user friendly document, which explains the possibly needed
manual steps needed to test the success of the conversion?
  --> User can ignore that, but it might help us get to know some bugs.
. How (in theory) is it assured that the conversion is working (I also
mentioned comparing the results of queries for being equal.
    --> Can this be automated (and as I said) the conversion to FireBirdDB only
succeed if (specific kinds of) queries are evaluated in exactly the same way as

Thanks for considering and / or answering above statements / questions.

You are receiving this mail because:
You are on the CC list for the bug.
Libreoffice-ux-advise mailing list

Reply via email to