Hacker News Reader

Comment by voidlogic | Hacker News Reader

If any gophers need a solid redis library I would recommend: https://github.com/garyburd/redigo

This is a mature library that I have been using for years.

(Author, here.) I also recommend garyburd/redigo. I especially like the API. Instead of adding methods for every Redis command, redigo uses a single Do() method and then has several "type helper" methods that allow you to convert the response to various types simply by wrapping Do():

    value, err := redis.String(client.Do("GET", "mykey"))

Of course, this means you need to know about every command's response type and adds an extra (if small) level of verbosity, but in practice it fits very well with Go's philosophy of handling errors often and early. So, for instance, you're encouraged to handle the possibility that your key doesn't exist rather than barreling ahead with an empty string.

That looks really verbose. Also, am I correct in thinking that redis.Integer(client.Do("GET", "mykey")) would be an error, even if you've previously stored a int value in the key? If so, that seems like a trap.

How is this better for error handling? Why couldn't client.Get("mykey") signal an error in the same way, rather than returning an empty string?

The statement

    value, err := redis.Integer(client.Do("GET", "mykey"))

sets the int variable "value" to the decimal integer stored in "mykey". The variable err is set to a non-nil value if the value cannot be parsed as a decimal integer, the key is missing, the key is not a redis string, the connection is broken or any other error.

This method of error handling is convenient because the application only needs to check for one error. The alternative is to do something like:

    v, err := client.Do("GET", "mykey")
    if err != nil {
       // handle command error
    }
    p, ok := v.(string)
    if !ok {
        // handle error where p is not a redis string
    }
    i, err := strconv.ParseInt(string(p))
    if err != nil {
       // handle parse error
    }

There is no trap. If the connection to the server is healthy and the value stored for "mykey" is a decimal encoded integer, then redis.Integer(client.Do("GET", "mykey")) returns that integer.

Another +1 from me. I've been using it to do 1000s of requests/second in a project for over a year now. It's a little bit of work in that you have to explicitly get then return a connection to the pool, but the "defer" syntax makes that as painless as possible.

+1 on this. I've used it in a previous project of mine. I did experiment with the other Redis-go libraries but Gary's felt the most complete and solid.

Reply on news.ycombinator.com