It's a little bit difficult: What is the bug? This is a summary about all, what has to be done before internal HSQLDB is set to deprecated. I will set this one to "New".

This laundry list looks a dupe to existing META bug 116968 for the migration capability and belongs there.

@Xisco, this fails all our QA steps, please adjudicate.

Created attachment 141489 [details]
Standard-database of Base-Handbook. Should be migrated completely.

I have added this database for testing the migration after all the reported bugs for Firebird-migration have been set to "Resolved". The database is the main example of the Base-Handbook. It's the example without macros. Could be macros need other kind of migration by the user ...

Hi Florian,
Thanks for reporting the bug, but IMHO, it would be much easier if each of the points in the list were reported in different bugs, remember,  divide and conquer.

On the one hand, we have some of the migration problem already reported in meta bug 116968, On the other hand, the already known firebird problems are reported in the meta bug 51780.

 
> - Converting HSQLDB databases from HSQLDB to Firebird should not be enabled
> by default in 6.1 -> Should be an experimental option.
>   - Expert configuration entry should be added to force / ask / delay upgrade
>    - In "RELEASE CONFIGURATION" builds default should be "delay", in others
> "ask".

It was discussed in last week's ESC meeting to enable it and ask the users whether to migrate or not. I guess the place to discuss such a rollback is the ESC meeting.

> 
> - After converting the ODB file there must not be the HSQLDB data in the
> file anymore.

I guess this can be discuss in bug 117072

>   - Ask to store in new file
> 
> - Automated tests should be created that cover the following aspects. The
> test document should be a HSQLDB one as explicitly the transition to
> Firebird should be tested:
> 
> - Relationships are working between tables:
>  - 1:1
>  - 1:n
>  - n:m
> 
> - Auto increment of elements working (needs to be checked after converting)
> - Other constraints on elements must work as well
>   - UNIQUE / PRIMARY KEY / FOREIGN KEY / NON NULL on single field
>   - UNIQUE / PRIMARY / FOREIGN KEY on group of fields
> - All different index types (TODO: what index types are supported) need to
> be mapped to corresponding INDEXES in Firebird
> - All different types need to be checked whether a corresponding type is
> available
>  - Same range / order behavior
>  - Incompatibilities need to be documented BEFORE deprecating HSQLDB backend
> to allow people to prepare for the transition. 
> - We need to discuss to what extend manually entered SQL needs to be covered
>   - However, views created by the designer must work
>   - Best effort approach for manually created views
> - As long as the HSQLDB driver is integrated we can easily check if the
> result of reports (or anything else relevant) is exactly the same compared
> to the HSQLDB version.
> - What to do with HSQLDB specific functions?
>  - Firebird 3.0 does not support concat in select
>    - Can be rewritten from "concat(A,B)" to "A || B" -> See above. How to
> handle SQL.

There're already some automated tests in https://cgit.freedesktop.org/libreoffice/core/tree/dbaccess/qa/unit
Anyway, more are welcomed, of course.

> 
> After automated testing of some (conversion works and reports lead results /
> entries can eb added) manual QA effort is needed. The timeframe to the 6.1
> seems to close to tackle everything listed above. Therefore defaulting to
> enabling this big feature for 6.1 is not recommended. As highlighted above
> incompatible data types / SQL code has not been discussed as part of the
> transition to Firebird.

 
> TODO from QA side: Prepare 1-3+ test documents, which should be used as data
> for automated tests. Ideally this should not only be new documents, but also
> documents created by older LibreOffice versions

For automated tests, better to create unittests than 1-3+ documents.
For manual tests, we have hundreds of databases in Bugzilla -> https://bugs.documentfoundation.org/buglist.cgi?f1=attachments.mimetype&list_id=795474&o1=casesubstring&query_format=advanced&v1=application%2Fvnd.oasis.opendocument.database

As said before, if there's anything not reported yet, please create one report for each problem.
Closing as RESOLVED WONTFIX

(In reply to Xisco Faulí from comment #4)

>> - Converting HSQLDB databases from HSQLDB to Firebird should not be enabled
>>   by default in 6.1 -> Should be an experimental option.
>> - Expert configuration entry should be added to force / ask / delay upgrade
>> - In "RELEASE CONFIGURATION" builds default should be "delay", in others "ask".

> It was discussed in last week's ESC meeting to enable it and ask the users
> whether to migrate or not. I guess the place to discuss such a rollback is
> the ESC meeting.

I don't think the ESC decision was so rigid as to require nagging the user
at each opening of an embedded HSQLDB file! The scheme proposed by Florian
is reasonable. Other reasonable schemes would be:

- Have a "don't nag again for this file" option in the dialog (which sets some
  property/setting/mark in the file)

- Instead of / additionally to initiating the migration through a pop-up, do
  it through anexplicit menu entry? If technically necessary, that menu entry
  could not act on the currently open file, but on another file that on
  chooses from the filepicker.

Depending on how much development/QA work we get squeezed in before 6.1,
we could start in 6.1 with a menu entry the user has to explicitly look for,
and switch to a pop-up when development/QA is more advanced. That is a decision
to be taken near feature freeze for 6.1.

> I don't think the ESC decision was so rigid as to require nagging the user
> at each opening of an embedded HSQLDB file! The scheme proposed by Florian
> is reasonable. Other reasonable schemes would be:
> 
> - Have a "don't nag again for this file" option in the dialog (which sets
> some
>   property/setting/mark in the file)

Reported in bug 117120