Hi,
the migration of a (single-user) database from one RDBMS to another
copes with 3 main families of issues:
(1) the SQLs are not compatible: each has its own dialect, the list of
builtin functions is different, etc. This is visible each time "Direct
SQL" is used in LO, i.e. when making a view or building the SQL
statement programmatically or as soon as the query you need is a bit
complex.
(2) the datatypes are not compatible: e.g. TIMESTAMP has a time zone in
Hsqldb, has none in Firebird, ...
(3) the limits are different: e.g. VARCHAR max. length is < 2Gb in
Hsqldb and < 32K in Firebird, the max. length of a table row is < 2Gb
in Firebird and <64K in Firebird, the max. length of a column name is
128B in Hsqldb and 31B in Firebird.
NB: the figures above are for Hsqldb 2.x, but, AFAIK they are also valid
for version 1.8. Source =
https://en.wikipedia.org/wiki/Comparison_of_relational_database_management_systems
All this means that a 100% correct and automatic migration of 98+% of
the worldwide LO + embedded Hsqldb files in use IS A DREAM.
My recommendations are:
- Forget forever the idea to firmly invite for a data migration at each
database opening.
- Replace this by a specific menu item by which the user DECIDES to (try
to ... ?) migrate.
- End the migration process with a "Save As ..." type of dialog to store
the result of the migration into a new file.
- If the migration was partial because of incompatibilities, an error
report should list them.
Other valid questions are: should we drop the migration functionality ?
Should we ever drop Hsqldb ? Should we propose Hsqldb 2.x (migration of
database is done by RDBMS itself ... :) ? Are there enough devs ? And,
finally, what are the real benefits of running Firebird i.o. Hsqldb for
our users when designing/running a NEW database ? And let's sell them,
if they exist !
My 2 cents.
Jean-Pierre
Le 20/08/19 à 10:28, Julien a écrit :
Hello,
Considering the number of bugs about Firebird migration (see https://bugs.documentfoundation.org/show_bug.cgi?id=116968) and the fact that these bugs may not be trivial to fix (see https://wastack.wordpress.com/2018/07/25/database-migration-in-libreoffice-bug-fixes-and-more/), thought it could be relevant to put Firebird back to experimental or at least stop to propose Firebird migration when opening an odb file with hsqldb embedded.
Remark: don't misunderstand me, I'd enjoy to replace HSQLDB to help to remove Java dependency. Also, I know that HSQLDB upgrade has been delayed/cancelled because we had plan to replace it by Firebird but let's face it, I don't think we're ready to propose Firebird widely.
Let's not forget there are too few dev experts working on Base part (Lionel + Tamás + Jean-Pierre Ledure for specific Access part).
(I'm trying sometimes to work on Base part but most of bugs are too difficult for me and require a good understanding of Base mechanisms).
Now perhaps I'm too pessimistic here, so would like your opinion.
Any thoughts?
Regards,
Julien
_______________________________________________
LibreOffice mailing list
LibreOffice@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/libreoffice
_______________________________________________
LibreOffice mailing list
LibreOffice@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/libreoffice
