To possibly save the rest of you time, after I spent too long on a pros and cons list (included below), I found and looked at the issues: https://gitlab.gnome.org/GNOME/libgda/issues?scope=all&utf8=%E2%9C%93&state=opened  Also see the list of closed issues, and also sort on when opened, the "shape" of that vs. open is bad.

The bottom line is that ignoring everything else, it's way too complex, way too buggy with leaks and segfaults, and most deadly, threading induced segfaults.

UNSAT for anything but I assume the lightweight desktop applications it's aimed at, as an explicit alternative to SQLite.

- Harold

[begin obsolete pros and cons list]

Now that we've narrowed down the databases we want to support well, we should consider GNOME libgda.  A as of 2009 "how to choose between libgda and SQLite" document lays out a lot of details: https://wiki.gnome.org/ChooseLibgdaSQLite

TL;DR of that and other stuff I've picked up, although I haven't :

Pros:

And I confirmed all of the above are in its source tree.

I wonder if any of us are eager to cobble together a native Java network interface for JDBC (then again it might already have been done), so assume if we did our own it would mostly be written in Kawa, perhaps making it slower.  But a lot more fun to do.

Seems to all be in C.

Claims as of 2009:

Cons:

LGPL 2.x, linking it to some existing Schemes is problematic.

It's threaded, don't know how, but that'll make it a lot more difficult to link with thread aware Schemes.  In general, it's from the class of applications that's as foundational as a Scheme implementation is.

In general, the issues include a serious refactoring of the existing "provider" AKA database driver architecture.

Enforces data typing on columns, so in return for getting MySQL and JDBC drivers, and others as gravy, we'd still have to write our own SQLite one for when we want dynamic typing on columns, but we'd probably rather do that than write a MySQL driver and keep it maintained, ditto perhaps to a lessor degree JDBC.

It's threaded, trying to link it to 

Has GLib, a/the? basic GNOME foundation library as a dependency.

Has libxml2, a XML document parser, as a dependency.

It's a lot of C code and complexity.  Here's a 2010 list of features: https://www.gnome-db.org/DetailledLibgdaFeatures

I would be surprised if we don't end up doing some serious C debugging of its innards upon occasion, we could well end up find corner cases that don't show up for desktop applications where SQLite is extremely viable.

Sounds like it would pretty much dictate our lower level architecture, and higher level feature set, in fact, it sounds like we'd be writing to its SQL parser, not the individual databases'.  Sounds like escapes to a lot of particular database features would simply not make sense in it's model.  Advanced PostgreSQL datatype users would probably not be happy at all, but given the vast differences between the datatypes it supports and the 4 SQLite does, that's ... going to take some thought.  Thinking out loud, if we do our own DBI, maybe a base set of standardized features and a formal way to mark and use advanced per database features???

It's from the GNOME project (eventually will be discarded when the last version of the GNOME desktop devolves to a single button labeled NO, which does nothing when you press it.... 1/2 :-).

More seriously, GNOME the desktop environment inspired the essay on the "Cascade of Attention-Deficit Teenagers" development model: https://www.jwz.org/doc/cadt.html  Bugs now live in its GitLab, and ... oops, see the real message at the top.

[end]