kexi + libreoffice

[Jaroslaw Staniek]

On 20 February 2014 14:11, Treeve Jelbert <treeve at scarlet.be> wrote:
> be aware that LibreOffice-4.2  has started a transition to using an embedded
> Firebird engine
>
> <https://www.libreoffice.org/download/4-2-new-features-and-fixes/>
>
> <http://en.libreofficeforum.org/node/6062>
>
>
> NEW TECHNOLOGY PREVIEW FEATURE: Firebird SQL connector for LibreOffice Base
> (Andrzej Hunt). When creating a new Database, select Firebird Embedded in the
> drop down menu (you have to first enable the Experimental features in Tools ▸
> Options ▸ LibreOffice ▸ Advanced). This allows creation of databases that
> perform many times faster than the previous built-in HSQLDB 1.8, avoiding the
> C++-to-Java overhead inherent in using HSQLDB. We plan to phase HSQLDB out
> over the next few releases, and provide a smooth migration path to Firebird.
>
> I think that the new format is simply a zip wrapper around a normal Firebird
> database.
>
> Firebird can be accessed directly using the Qt4/5 InterBase  (QIBASE) driver

Hello and thanks for the info, Treeve.
I'll read the discussions. Good that there's departure from the
C++-Java hybrid. Awesome work.

I decided CC'd Andrzej Junt - I am very interested in opinions and
just staying in contact...

For now I hope the schema in the content.xml file will be still
available. If so, the HSQL import and the FireBird would share a
common part.

Regarding keeping the habit of zipping a binary format that was
designed for random access... I hope that could be made in a way ow MS
Access (files) and Kexi (files) are organized, ie. in a single
database binary. But maybe there is a strong point against that idea.

BTW, I guess we all know, switching between db backends is not a
matter of drop-in. At least SELECT queries would be not portable.
Maybe also CREATE TABLE, in some aspects.
This is in part a reason why Kexi has own SQL parser and generates
native SQL internally - it never presents native SQL to the user or
lets the user enter it. After all that's in part an original, never
developed idea of full ODBC (before MS has stepped in).

BTW#2, switching backend in Base implies changes to the file format,
other than the storage method. In ideal world that would be an
opportunity to share as much of the format between Kexi and Base as
possible.

> Other suggestions;
>
> 1. remove need for QT3SUPPORT from Kexi.

This is the near plan :)

> 2. add a generic import filter from Firebird.

FireBird support would even materialize as a kexidb driver (for live
access, not just import).

We have considered and evaluated Firebird in 2004 for Kexi but for
some reasons SQLite won even if the former is more complete, eg.
offers the beloved ALTER TABLE.

So of course I'd welcome maintainer of such driver.

> 3. start to port Kexi to KF5

This is the plan :)

-- 
regards / pozdrawiam, Jaroslaw Staniek
 Kexi & Calligra & KDE | http://calligra.org/kexi | http://kde.org
 Qt for Tizen | http://qt-project.org/wiki/Tizen
 Qt Certified Specialist | http://www.linkedin.com/in/jstaniek