Re: [Chicken-users] DBI

[Ozzi Lee]

> I suggest that a row be an a-list, and that null columns be represented
> by being non-existent in the a-list.  If you end up preferring a plain
> list or a vector, then use (void) instead -- I am trying to get this
> standardized as the Chicken representation of SQL's NULL.

I like a-lists as rows for well. I'm not sure about null columns not 
existing, I think I like it but I guess I'd have to think about/play 
with it. Otherwise I agree (void) is probably a good idea.

> In reality, though, I think portability between databases is more
> hypothetical than real.  Projects typically start with one database and
> stick to it, for moving between databases *even if a portability layer
> is in use* turns out to be hard -- all sorts of stuff outside the main
> code base ends up changing (path names, load scripts, whatever).

I agree that portability isn't that great in practice. I'd like to see a 
DBI egg for two reasons:

1. Starting out on a project, 90% of the time I'll use SQLite, because 
it's the easiest. Often I'll want to switch to MySQL once things get 
rolling. A single DBI interface makes this quite a bit easier.

2. For quick and dirty scripts that need to access a database, it would 
be nice to have to keep in the differences between the different interfaces.

I would like for a DBI egg itself to be as agnostic as possible. SQL 
implementation issues (DBI won't mess with SQL at all) and outside 
scripts aside, do you know of any incompatibilities that would affect this?