Is there any way we could specify a meta-API as it were that standardized the things pretty much every database of this sort has, like connecting and querying (query language agnostic, but data types in and out are problematic), and ... publishes, or exposes in some way extensions, which I suspect most every significant database has?
And/or these extensions and differences having a naming convention to facilitate finding their use in an existing code base?
To me, the only thing that *really* makes SQLite a *completely* different animal is its dynamically typed columns, but I suppose that comes from my systems administration experience. Single file zero-admin is a different beast administratively, that should make you much more prone to use it, and there's no good reason to not expose and take advantage of its API level special features. I just want common usage patterns to be regularized to the extent that makes sense.
- Harold
----- Original message -----
From: John Cowan <xxxxxx@ccil.org>
Date: Monday, September 16, 2019 8:50 AM
This is part of an argument that an in-process, single-file, zero-admin SQL database is a completely different animal from an interface to SQL database servers, and deserves its own API, though it should not be *gratuituously* different. The existence of sql-de-lite and APSW (Python) seemed to confirm this. Once you exclude the proprietary, the JVM, and the .NET databases, only SQLite and Firebird Embedded are left, and SQLite is far more lightweight.
My actual pre-SRFI isn't particularly SQLite-specific, but it's what I think of as the MVP; other SQLite-specific features can be added in a later SRFI. If it's useful as a skeleton for a general database server API, that's certainly a Good Thing.
On Sun, Sep 15, 2019 at 09:34:08PM -0400, John Cowan wrote:
> One of the other things that makes SQLite different is the ability to
> define scalar and aggregate functions, as well as collations, on the fly.
I'd say treat it as an extension. This is so different from the typical
client/server database that it doesn't make much sense to standardise in
the API.
Similar for LISTEN/NOTIFY in Postgres, as a random example which also
involves callbacks.
Cheers,
Peter