3 ms·

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

If any gophers need a solid redis library I would recommend: https://github.com/garyburd/redigo https://github.com/garyburd/redigo This is a mature library that I have been using for years.

nrmn 12y ago
+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.
guywithabike 12y ago
(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.
- eurleif 12y ago
  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?
  - BarkMore 12y ago
    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.
pkulak 12y ago
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.

If any gophers need a solid redis library I would recommend: https://github.com/garyburd/redigo https://github.com/garyburd/redigo This is a mature library that I have been using for years.

nrmn 12y ago

+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.

guywithabike 12y ago

(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.

eurleif 12y ago
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?
- BarkMore 12y ago
  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.

pkulak 12y ago

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.