Re: About putting back Firebird experimental

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux