Call for testers - automatic migration of embedded hsqldb Base files to embedded Firebird Base files

users
#1

Hi all,

One of TDF's recent tenders was to provide a means to automatically
migrate embedded hsqldb ODB files to embedded Firebird ones.

This has now been accomplished by Tamas Bunth, working for Collabora,
and the code pushed to the master branch, so it should already be
appearing in daily builds.

Testing is needed to report any problems.

At present, as I understand it, the conversion process is automatique
and transparent, which means that in principle, the change is invisible
to the user (bar any import errors, I imagine).

The change is also irreversible, which means that at least for testing
purposes, you should only use copies or specifically engineered test ODB
files at the moment.

The irreversible nature of the transformation means that it will no
longer be possible for older versions of LO that do not support
integrated Firebird databases (4.x and older ?) to be able to open the
newly migrated ODB files.

Please report any migration errors to the LibreOffice bugzilla.

Alex

#2

Hi *,

have tested this kind of migration:

Downloaded the daily build of 2018-04-11, 6.1.0.0.alpha0+
Opened the database, which is part of the Base Handbook:
"Media_without_Macros".
No comment like "Internal HSQLB" apperas at the bottom of the window.
Tried to open the tablecontainer.
No table apperas, but after some time the following message:

Connection to datasource "Media_without_Macros" couldn't be established.

firebird_sdbc error:
*Dynamic SQL Error
*SQL error code = -104
*Token unknown - line 1, column 163
*BLOB
caused by
'isc_dsql_prepare'

I haven't set the experimental features to "yes". I wasn't asked if I
want to change the database from HSQLDB to Firebird.

Base should never be a playground for such a function. People will loos
their data and will never again use LO after starting one database with
this automatic.

1. An automatic migration should never be installed from a working
internal database to a database, which is an "experimental feature"
(Firebird) - and never means: also never with a daily build.
2. A migration should only be offered, never automatically, when
internal Firebird database has been activated.
3. The migration should create a new database with the migrated content,
not overwrite the old database.

Regards

Robert

#3

Hi all,

have put the content of the mail I wrote to a bug-report:
https://bugs.documentfoundation.org/show_bug.cgi?id=116944

Regards

Robert

#4

Thanks Robert.

Tamas has indicated on the dev mailing list that the binary content of
the hsqldb database remains stored in the ODB:

"In the current state, the old HSQLDB data is also kept in the odb file
after migration. You can revert the migration by unzipping the odb
file and overwriting the URL in content.xml in tag
<db:connection-data>.

Besides that, the migration will be permanent only if you save the
document and a red circle on the save button indicates that something
has been changed."

I somehow doubt that this will be seen as a suitably satisfactory
solution for most users...

Alex

#5

I think that this specific announcement should be evaluated carefully to
avoid a disruptive impact on the user base (although the number of Base
users is small in comparison with the global number of users, the are
people and organizations which do rely on Base for their data).

So, any "radical" deprecation of features should be evaluated not only
in technical terms, but also in marketing/communication terms. We cannot
get rid of a feature without giving users a reasonable amount of time to
migrate their data (and the fact that they are embedded in the zipped
file is not a solution for most users, who are not even aware that files
are zipped folders which include all document components).

#6

Italo Vignoli-5 wrote

...

So, any "radical" deprecation of features should be evaluated not only
in technical terms, but also in marketing/communication terms. We cannot
get rid of a feature without giving users a reasonable amount of time to
migrate their data (and the fact that they are embedded in the zipped
file is not a solution for most users, who are not even aware that files
are zipped folders which include all document components).

Covered at the weekly ESC meeting [1]. With some discussion in gerrit where
the commit was backed out [2], and legacy HSQLDB support restored. Seems
conversion to Firebird would become optional at 6.1, and new Base data
likely being the Firebird engine.

As of this evenings builds of master the FB3 driver is back to
experimental, so Tamás' request for Firebird data testing in Base is on hold
as this gets sorted.

=-ref-=
[1]
http://nabble.documentfoundation.org/Libreoffice-qa-minutes-of-ESC-call-td4237769.html
[2] https://gerrit.libreoffice.org/#/c/52731/

#7

As I understand it, the commit you link to refers to a revert of the
removal of support for embedded hsqldb (and the corresponding change to
Firebird as default).

If the back-out is complete, i.e. master has returned to the previous
status quo, this is unfortunate for those of us who would like to test
whether the migration works and report those issues to bugzilla...

Can one still test the automatic migration or not ?

Alex

#8

Alex Thurgood wrote

If the back-out is complete, i.e. master has returned to the previous
status quo, this is unfortunate for those of us who would like to test
whether the migration works and report those issues to bugzilla...

The back-out is not complete--and LO base is actually broken judging from
last nights tinderbox build [1]. Seems like the Firebird driver support is
not being found to drive the migration which is still active. Believe devs
are going to have to readjust Firebird to allow us to get back to testing
conversion--including new code to "offer" to do the conversion.

Can one still test the automatic migration or not ?

At the moment seems not.
=-ref-=

[1] Version: 6.1.0.0.alpha0+ (x64)
Build ID: 55e84652ae84bd2374462ee19afd359a8cc90b95
CPU threads: 4; OS: Windows 10.0; UI render: GL;
TinderBox: Win-x86_64@42, Branch:master, Time: 2018-04-13_05:08:28
Locale: en-US (en_US); Calc: CL