Hi, all.
I've been writing a SQLite interface for CMUCL,
which is public domain and up for download at
http://www.randallsquared.com/download/sqlite/cmucl-sqlite3/ .
The latest version as I write this is 0.5, and it
seems minimally feature-complete, if not as fast
as it could be. You can learn more about it by
reading the source or reading the HTML doc at
http://www.randallsquared.com/cs-doc.shtml .
I'd be very interested to hear criticism or other
feedback on it.
--
Randall Randall <·······@randallsquared.com>
Property law should use #'EQ , not #'EQUAL .
On Sat, 11 Dec 2004 17:17:23 -0500, Randall Randall <·······@randallsquared.com> wrote:
> I've been writing a SQLite interface for CMUCL, which is public
> domain and up for download at
> http://www.randallsquared.com/download/sqlite/cmucl-sqlite3/ .
How does this differ from the SQLite backend included in CLSQL?
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz wrote:
> On Sat, 11 Dec 2004 17:17:23 -0500, Randall Randall <·······@randallsquared.com> wrote:
>
>
>>I've been writing a SQLite interface for CMUCL, which is public
>>domain and up for download at
>>http://www.randallsquared.com/download/sqlite/cmucl-sqlite3/ .
>
>
> How does this differ from the SQLite backend included in CLSQL?
There are some trivial differences, and some
differences of expectation.
The trivial ones include
1) CMUCL, rather than UFFI, dependency
(reason: last time I tried (months ago), UFFI didn't
seem to support CMUCL on PPC, and that's my primary
development platform)
2) caches prepared statements, instead of throwing them away
3) supports the SQLite version 3 binding API
4) license is public domain (like SQLite), rather than LLGPL
5) doesn't provide a default database argument
6) provides higher level functionality than the db-sqlite3
backend, and lower level (in some ways) than CLSQL itself
The more general differences are that cmucl-sqlite3
is intended to be the developer interface, rather
than the backend of a higher level that has it's own
database-agnostic constructions. This means that I
can trivially support the binding API, which makes
avoiding SQL injection painless with no particular
quoting required. I'm sure CLSQL solves this in some
way at a higher level, but I haven't looked into it.
In the future, I can directly support the PRAGMA
directives to SQLite (which may have no analogue in
some other databases), though cmucl-sqlite3 does not
currently do anything at all with PRAGMAs. I notice
that the CLSQL backend *does* have a PRAGMA directive
in it, so this isn't to claim that they couldn't do
that, but rather, that such a thing has only limited
use when the goal is to provide an identical or very
similar interface across multiple RDBMS.
In any case, SQLite performs *far* more quickly (in
the neighborhood of 100x the speed, per the SQLite
mailing list) when multiple insert or update statements
are contained within transactions. cmucl-sqlite3 does
this automatically. It was faster to make my own
interface that did this than to figure out whether
CLSQL did it. Okay, that's an exaggeration. Probably.
CLSQL (and cl-sqlite, Alain Picard's SQLite version 2
library) both assume that one has a default database
that one wants to work with. With PostgreSQL, this was
true for me, but SQLite's model works more flexibly if
one has a database open for each kind of thing (each
package might have one or more open; you might have a
database fully in memory which is used as a cache for
an on-disk one, etc). To that end, cmucl-sqlite3 does
not provide any default database argument, since in the
kind of development I typically do, it would only very
rarely be the right database.
cmucl-sqlite3 is intended to be more like cl-sqlite than
like CLSQL, however, and I only chose to write my own
rather than contribute to Mr. Picard's because his
Lispworks FFI used callbacks for the data retrieval,
and I didn't feel like learning Lispworks FFI just to
rewrite this for CMUCL when I couldn't even write it
in the same style (CMUCL for PPC doesn't currently have
working callbacks from C in the FFI). It only took a
coupla weeks to write both a version 2 and version 3
interface, however, so it isn't as if I spent a lot of
time on it. :)
As it is, this interface can now grow into something
that natively supports Unicode, automatic RAM caching,
and all the PRAGMA directives that SQLite supports.
All this may have been more information than you wanted,
but I hope you can pick out the part for which you were
looking.
--
Randall Randall <·······@randallsquared.com>
Property law should use #'EQ , not #'EQUAL .
On Sun, 12 Dec 2004 03:38:50 -0500, Randall Randall <·······@randallsquared.com> wrote:
> All this may have been more information than you wanted, but I hope
> you can pick out the part for which you were looking.
That was very helpful. Thank you.
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")