What is the status of this effort?
I have written a *very* simplistic DBI which supports lowest common
demoninator access to sqlite3 and postgresql. It is only 90 or so lines of
code but so far seems enough to let me write for sqlite and switch to
postgresql etc.
I'd be interested in making this into an egg if anyone thought it'd be
useful to them but I don't want where we have multiple solutions to the
same problem on the eggs page so I'll pass if the "real" dbi is coming to
market any time soon.
Let me know, eggify or put on snippets or wait for real dbi? Also, if I did
make it an egg what to call it? sdbi for simple dbi?
;;
;; sqlite3 example simple test code for
;;
(use sqlite3)
(system "rm -f tests/test.db")
(load "mrwdbi.scm")
(dbi:open 'sqlite3 '((dbname . "tests/test.db")))
(dbi:exec db "CREATE TABLE foo(id INTEGER PRIMARY KEY,name TEXT);")
(dbi:exec db "INSERT INTO foo(name) VALUES(?);" "Matt")
(dbi:for-each-row
(lambda (tuple)
(print (vector-ref tuple 0) " " (vector-ref tuple 1)))
db "SELECT * FROM foo;")
(dbi:close db)
(system "rm -f tests/test.db")
;;
;; postgresql simple test code
;;
(system "dropdb test")
(system "createdb test")
(use postgresql)
(load "mrwdbi.scm")
(define db (dbi:open 'pg '((dbname . "test")
(user . "matt")
(password . "**********")
(host . "localhost"))))
(dbi:exec db "CREATE TABLE foo(id SERIAL PRIMARY KEY,name TEXT);")
(dbi:exec db "INSERT INTO foo(name) VALUES(?);" "Matt")
(dbi:for-each-row
(lambda (tuple)
(print (vector-ref tuple 0) " " (vector-ref tuple 1)))
db "SELECT * FROM foo;")
(dbi:close db)
(system "dropdb test")
On Saturday 01 March 2008 10:26:45 am Vincent Manis wrote:
On 2008 Feb 29, at 23:13, Alex Shinn wrote:
However, different backends represent
this (and various other extensions we'll eventually want) in
different ways. SQL could just generate a standard syntax
that all the backends would have to support, but then they'd
be reparsing the SQL string we just generated and then
putting it back together in their own way. It makes more
sense to integrate the SQL generation with the backends from
the start.
This all sounds uncomfortably like ODBC to me. I would not
use a module like that, but would use a DBI-like module,
for the reasons we discussed a couple of days ago: prototyping,
relatively quick-and-dirty applications, and teaching.
A caution against overengineering isn't out of place here.
What is the problem this high-level API is trying to solve?
-- vincent
_______________________________________________
Chicken-users mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/chicken-users