Re: About putting back Firebird experimental

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@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/libreoffice