Bug 117376 - Firebird: Migration: Migration function should not mix the HSQLdb and Firebird schemas in the same altered ODB file
Summary: Firebird: Migration: Migration function should not mix the HSQLdb and Firebir...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
6.1.0.0.alpha1+
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Database-Firebird-Migration
  Show dependency treegraph
 
Reported: 2018-05-01 14:30 UTC by Drew Jensen
Modified: 2023-05-05 03:24 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Drew Jensen 2018-05-01 14:30:43 UTC
Description:
Currently the auto-migrate function works by adding a firebird db into the ODB content and leaving the existing HSQLdb db files intact. This was presented as a good way not to loose data during the migration in that it would be easy to revert back to the hsqldb:sdbc driver by just updating the settings in the ODB content. 

However also as part of the auto migration the function may alter items external to the db (schema) to account for differences between database engines and stored in ODB file content.

For very simple migrations just setting the sdbc setting would be make the ODB usable, however the migration function also supports changes whih would make using the ODB problematic at best, broken at worst. 

Possible changes include:
changes to SQL select statements which could be in a querydef, form, report or macros.

Table, View, Column names may need to be shortened during the migration and again that ripples out through the objects above.



Steps to Reproduce:
1. Open any hsql based ODB
2. Start the migration
3. save the file

Actual Results:  
Firebird database file is included in the ODB, ODB set to use firebird:sdbc; necessary fixups to querydefs, reports etc are done, hsqldb data files remain in file.

Expected Results:
not sure.


Reproducible: Always


User Profile Reset: No



Additional Info:


User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/65.0.3325.181 Chrome/65.0.3325.181 Safari/537.36
Comment 1 Drew Jensen 2018-05-01 14:40:04 UTC
Regarding SQL statements, not all changes would be problematic, particularly if favor is given to changes which would alter statements known to a common dialect.
Comment 2 Drew Jensen 2018-05-01 16:06:49 UTC
Regarding forms and reports

Both Form files and report files could be backed up to an added sub list in the odb
forms/Form1
add sub list hsqlbak
copy Form1
forms/hsqlbak/Form1

migration routine does any needed fixup to forms/Form1
Comment 3 Drew Jensen 2018-05-01 16:19:29 UTC
Sorry for the noise of multiple comments.

Another issue here is what happens if the user does revert the odb to hsql:sdbc for whatever reason.

Right now that odb would fail an auto migration run because a firebird db and schema exist prior to the function start. It will fail when it trys to create the schema objects.

Sure it could be handled by having the function check or drop it first, but its adding complication that could of been avoided.

ps - the comment about backing up forms and reports should of included:
(by lists I meant directories)
if there was no need to fixup anything in forms or reports just drop the backup directory or leave them there so the file can be reverted to hsqldb:sdbc again.
Comment 4 Robert Großkopf 2018-05-02 05:33:38 UTC
The migration hasn't be done with only migrating tables, forms and relations. Could be you have to change queries, forms, reports and macros also - and all this isn't saved for the internal HSQLDB.

I couldn't understand why it shouldn't be possible to create the migrated Firebird database as a new database. If I open a database and could change something inside the database, I have write-access. The *.lck-file is also written. The only problem could be there isn't enough space available for a new database in the opened folder. But must of the content of a database-file is the database itself. And if I migrate with two databases in one file the file could also expand to much as described before.

I will set this one to NEW.
Comment 5 Drew Jensen 2018-05-03 20:48:30 UTC
Have been thinking this through more, particularly as I keep running more ODB files through and I think I am wrong.

IMO the summary of this enhancement request for the current migration function is  LibO should create a backup of the ODB file, as is, as the first step of the migration after the user starts the process.

The old and new databases though should stay in the same physical file.
Comment 6 QA Administrators 2019-05-04 02:57:03 UTC Comment hidden (obsolete)
Comment 7 QA Administrators 2021-05-04 03:45:53 UTC Comment hidden (obsolete)
Comment 8 QA Administrators 2023-05-05 03:24:25 UTC
Dear Drew Jensen,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword


Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug