Re: [Chicken-users] DBI

[Matthew Welland]

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



-- 
http://www.kiatoa.com, fight for a better world.