[Top][All Lists]

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

Re: [Chicken-users] Redis-client issues

From: Carl Douglas
Subject: Re: [Chicken-users] Redis-client issues
Date: Mon, 20 Aug 2012 08:51:28 +0900

Hi Matt,

Thanks for reporting these bugs! 

 I am overseas on holiday at the moment and the soonest I will be able to take 
a look is next week after the 26. 

Regardless, you are welcome to fix these yourself, and I would encourage it! 

The redis-client.scm code is minimal and does not specialise per redis command.

Also you may like to consider an alternative redis implementation for chicken 
scheme, there is one hosted on somewhere I believe. 

Nevertheless I would like to see improvements made to the redis-client egg and 
intend to take a look at the problems you mention when I get back.


On 20/08/2012, at 2:23, Matt Gushee <address@hidden> wrote:

> Hi, Chickeneers--
> I'm back again! Though I have never been a key member of this community, so 
> you are forgiven for not remembering me ;-)
> Anyway, I am planning to develop a rather ambitious project using Redis, and 
> have been experimenting with the redis-client egg. Thanks to Carl Douglas for 
> developing it! But I have noticed a couple of minor problems with the egg; 
> one at least is surely a bug. Oh, and I am using version 0.7 of the egg with 
> Chicken 4.7.0 & Redis 2.4.15 on Arch Linux.
> Issue #1
> -----------
> Nil responses are not handled in some cases, e.g.:
>   csi> (redis-hset "goodies" "wine" "merlot")
>   (1)
>   csi> (redis-hset "goodies" "cheese" "gouda")
>   (1)
>   csi> (redis-hget "goodies" "wine")
>   ("merlot")
>   csi> (redis-hget "goodies" "cheese")
>   ("gouda")
>   csi> (redis-hget "goodies" "fruit")       ; Querying a non-existent field
>   ; never returns
> When I do this in the command-line client (redis-cli), the response is (nil) 
> . At any rate, it is handled gracefully. Should be in our library, too, I 
> would think.
> Issue #2
> -----------
> I don't know if this is really a bug, or just a feature I don't like, but if 
> a Scheme error (such as invalid input) is raised in the midst of a 
> transaction, the client seems to be rendered useless.
>   csi> (redis-multi)
>   ("OK")
>   csi> (redis-sadd "abc" "def")
>   ("QUEUED")
>   csi> (redis-hset "xyz" '())
>   Error: (string-length) bad argument type: ()
>         Call history:
>         <syntax>          (redis-hset "xyz" (quote ()))
>         <syntax>          (quote ())
>         <syntax>          (##core#quote ())
>         <eval>    (redis-hset "xyz" (quote ())) <--
>   csi> (redis-sismember "abc" "def")
>   ("QUEUED")
>   csi> (redis-lpush "fubar" "baz")
>   ("QUEUED")
>   csi> (redis-lpop "fubar")
>   ("QUEUED")
> In other words, any further commands simply produce the response ("QUEUED"). 
> Now, I have found that I can write an exception handler that calls 
> (redis-discard), and that seems to solve the problem. But what would make the 
> most sense to me is to build an exception handler into the client library 
> that would discard the transaction and then re-raise the exception. What says 
> the community?
> Also ... though I'm far from an expert Schemer, if Carl is not available to 
> work on this stuff, I will attempt to fix the egg, and if I am able to do so, 
> I'd be happy to contribute my fixes to the community.
> --
> Matt Gushee
> _______________________________________________
> Chicken-users mailing list
> address@hidden

reply via email to

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