[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/1.4.2.3i |
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.
Cheers,
Peter
--
http://sjamaan.ath.cx
--
"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
pgpiqj1UO474Q.pgp
Description: PGP signature
- [Chicken-users] DBI, Ozzi Lee, 2008/02/27
- Re: [Chicken-users] DBI, John Cowan, 2008/02/27
- Re: [Chicken-users] DBI, Ozzi Lee, 2008/02/27
- Re: [Chicken-users] DBI, Jeremy Sydik, 2008/02/27
- void as a return value (Re: [Chicken-users] DBI), Vincent Manis, 2008/02/27
- Re: void as a return value (Re: [Chicken-users] DBI), Ozzi, 2008/02/27
- Re: void as a return value (Re: [Chicken-users] DBI), John Cowan, 2008/02/27
- Re: void as a return value (Re: [Chicken-users] DBI), Vincent Manis, 2008/02/27
- Re: [Chicken-users] DBI, John Cowan, 2008/02/27
- Re: [Chicken-users] DBI, felix winkelmann, 2008/02/28