[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-users] DBI

From: Peter Bex
Subject: Re: [Chicken-users] DBI
Date: Wed, 27 Feb 2008 22:04:51 +0100
User-agent: Mutt/

On Wed, Feb 27, 2008 at 02:47:14PM -0600, Jeremy Sydik wrote:
> I've been working a little in the same vein, but it's still pretty  
> tied to a specific project
> My needs are pretty light, but I'm finding that the most useful  
> functions seem to be
> sql:query-list
> and
> sql:query-alist
> I'd like to look at the
> suggested functions:
> dbi:num-rows => I've found that I almost always end up using (length)  
> instead.  Probably not
>       optimal, but I've not had a major problem here.
> dbi:fetch-row => I've not used this either, but I'm usually pushing my  
> queried list into a for-each
>       or a map.  the question is, what is our specific use case?
> dbi:query-fold, dbi:query-map, query-for-each.  I thought about  
> implementing these, but I
>       haven't been able to think of the use case that makes them necessary  
> in the presence
>       Scheme's fold, map, and for-each, other than as shorthand (which  
> could be define'd
>       in place in a heartbeat for anyone who wants it)

No.  If you want to look at a result set that consists of several hundred
binary blobs of megabytes each, you most certainly don't want to implement
this as a "fetch all into one list" operation.  You would want to load in
one row, handle it, then take the next, etc.

As I've mentioned on the wiki (can we please move the discussion there?),
instead of using these particular three procedures, I'd prefer it if DBI
would just return a SRFI-41 stream so that the user has a proper list
library at his disposal, without the problems I've described above.
(the GC could clean up rows whenever needed)

> dbi:insert-id  Should this come from a function, or should it be  
> returned as a response to
>       dbi:query?  I wouldn't mind seeing the query handler be smart enough  
> that if my query
>       involves INSERT and i've inserted a row that becomes ID 42, that the  
> response would
>       be something like '((rows-affected 1) (insert-id 42)) Certainly, we'd  
> want to look at what
>       we'd want to normalize these labels to, but that's not a huge issue.

Sounds like a good idea.  Why make it two operations if you can do it in one
you will very often want to call anyway?

>       The related question is whether singleton response values (like rows- 
> affected with
>       nothing else) should return as a singleton (a)list or as a numeric  
> value --> My vote would
>       be to return the singleton (a)list  to simplify the conditional  
> checking the caller needs
>       to use.

Returning the same type of result value always is a Good Thing, I agree.

> This leaves
> (dbi:connect driver-proc [[connection params]])
>       In my case, I'm using SRFI-89 style define* for named params and  
> defaults.  What do
>       other people think of this approach?

I'm not sure about this point yet.  I'm more concerned about how to
specify what implementation to use.  You wouldn't want DBI to have all
other database eggs as its dependencies.  If you only want to connect to
a MySQL db, you only should need that egg.

> Row representation.  I think my preference would be using alists as  
> the the representation
> Thinking about it, Scheme already gives us everything we need to get  
> value lists, vectors,
> and hash-tables if we start from alists, so it seems like the better  
> choice.

Indeed, alists sounds best.

> I've tended to let null be '(), but that partly comes from liking the  
> look of
> (null? (alist-ref 'field result))  I'm not entirely comfortable with  
> leaving the
> value entirely absent simply because the mapping I mention to value
> lists and vectors becomes more problematic.  That said, my usage of
> value lists and vectors is limited enough that I'm not that tied to it  
> either.

Can you even check for void?  Afaik there's no VOID? procedure.

"The process of preparing programs for a digital computer
 is especially attractive, not only because it can be economically
 and scientifically rewarding, but also because it can be an aesthetic
 experience much like composing poetry or music."
                                                        -- Donald Knuth

Attachment: pgpiqj1UO474Q.pgp
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]