alternatives to Firebird: sqlite

[Lionel Elie Mamane]

On Tue, Mar 08, 2016 at 09:59:18AM +1100, Chris Sherlock wrote:

> Oh, and I’m not sure if this brings much to the table, but I wonder
> if we can simulate joins. After all, to get a right join you just
> swap tables, and you can actually simulate a full outer join with
> just a combination of other joins.

See the last part of
https://lists.freedesktop.org/archives/libreoffice/2016-March/073572.html
"compatibility with other databases" was a reference to
https://bugs.documentfoundation.org/42165
https://cgit.freedesktop.org/libreoffice/core/commit/?id=c25bb400bbfe20b3b13237ed10935ec9d0f6d769

In short: yes, it can be done.

All these issues add up, and in the end I summarise them as "It is
probably possible to build a 'compliant' database on top of SQLite,
but SQLite is not that by itself". That is, we can "use" SQLite as a
(big) chunk of our embedded database engine, which we would DEVELOP
OURSELVES, but it is not "take a database engine and embed it in
LibreOffice". It is "develop our own database engine, using SQLite as
a foundation that gets us many many percent of the way, but not the
full way". If someone wants to do that, and commits to maintaining it,
then fine. Glad to take patches / see it integrated. *If* it comes
with a serious intent of maintaining it! Note that the ODBC driver
basically does that. So yeah, doable. Can be redone. Maybe we could
even embed the ODBC driver in some way. I have some uncertainties
around this, because I think that ODBC drivers "need" a driver manager
(that's what the Microsoft documentations say somewhere), but I never
really understood completely why, and some FLOSS ODBC drivers *are*
meant (by their author) to be able to be used without driver manager,
I think.

See also
https://bugs.documentfoundation.org/show_bug.cgi?id=38811#c21


What SQLite does it not necessarily bad, it is *different*. Dynamic
typing has its uses and its advantages. Just as NoSQL. But it makes
them a "bad fit" for a framework centred around the "classic" / usual
strong-type SQL.

-- 
Lionel