[Larceny-users] sqlite3 FFI

[Peter Keller]

On Sun, Jun 01, 2008 at 08:52:16AM +0100, David Rush wrote:
> If you are programming a lot in Scheme, you will end up making those
> higher-level abstractions almost as a matter of breathing. The system
> I posted a few days ago for MySQL has several of them which are based
> around my own analysis of the question of how a DB engine should be
> related to fairly flat, transparent data structures such as Scheme
> provides.

At this time, I don't have that much experience as a DB engine user. I
have a project in mind which relies extensively on a relational DB
though, so I'm in the process of learning the ins and outs of SQL and
DB engine use.

> I would
> hope that everyone's interfaces to relational DBs might all settle
> down enough to write a SRFI for it, but somehow I doubt that anything
> resembling a community consensus even exists.

Given what I've seen with postgresql, mysql, and sqlite3, I'm not sure
an SRFI can be made at the level of the FFI to those DB. The only way
I see an SRFI being made is someone creating a scheme-like varient
of SQL example: (select (id name age) from table (where (eqv? 2 id)))
building an SRFI on THAT (along with certain operations on a DB like
how many rows changed, vacumming, etc, etc, etc) and then wedging that
into whatever offbeat SQL dialect a specific DB implementation requires.
I'm definitely not smart enough in relational databases to pull off that
kind of abstraction at this time and the SQL language as it currently
stands is a nice enough syntax.

For what it is worth, I've basically followed Chicken's sqlite3 interface
when I wrote mine. There are currently some small differences, like I'm
not sure what collation is in term of sqlite3, so I haven't copied that
portion of the interface.

I was just asking about the abstractions because I simply don't want to
be too clever and I don't have a lot of experience using a DB in code,
so I don't have a good feel for what the abstractions should be beyond
the obvious ones.

Thank you.

-pete