On 20 February 2014 14:11, Treeve Jelbert <tre...@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 _______________________________________________ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
