02:38:05 GMT <_Cory_> Hey, don't suppose there's a better way to get the number of entrys in a hash table than what I'm doing now? Getting all the entrys seems... Dirty?
10:27:02 GMT <_Cory_> Hey, don't suppose there's a better way to get the number of entrys in a hash table than what I'm doing now? Getting all the entrys seems... Dirty?
10:39:34 GMT <badboy_> _Cory_: how about HLEN?
10:40:20 GMT <_Cory_> Thank you badboy_, is that not in the docs? It won't come up on a google..
10:40:27 GMT <badboy_> it is
10:40:30 GMT <badboy_> http://redis.io/commands#hash
10:40:39 GMT <badboy_> don't google, use the command page!
10:41:30 GMT <_Cory_> Will do, thank you very much! Don't suppose you know the jedis equivelant off the bat?
10:41:46 GMT <_Cory_> hlen yeah
10:41:48 GMT <_Cory_> Thank you :)
15:05:30 GMT <JFlash> hi
15:05:39 GMT <JFlash> how does something like this work?
15:05:41 GMT <JFlash> https://www.npmjs.com/package/redis-geo
15:05:55 GMT <JFlash> do I have to like, put the geo data in redis so that it can work?
15:06:15 GMT <JFlash> or is it something built in to Redis?
15:06:28 GMT <JFlash> if I have to put the data, what can I use to put it in?
15:06:41 GMT <JFlash> (disclaimer:  I'm not a server side programmer)
15:11:54 GMT <minus> JFlash: it's actually cheaper to put the geoip data into your app than into redis, if you can affort the extra memory usage in the app
15:12:16 GMT <minus> also, that page you linked even tells you how to import data into redis
15:16:02 GMT <JFlash> in this discussion someone says I'd need close to 1 gig of memory just to keep this kind of data in a in-memory db such as Redis... am I reading it wrong??
15:16:02 GMT <JFlash> minus, how do I put it "in my app"?
15:19:35 GMT <JFlash> minus, how do I put it "in my app"?
15:24:54 GMT <minus> you go look for a maxmind geoip library instead
18:21:55 GMT <potatoe`> hello, does anyone know I can store json payloads in a list or a channel without redis escaping my double quotes?
18:27:08 GMT <minus> potatoe: redis treats your data as binary
18:27:19 GMT <minus> only redis-cli escapes stuff
18:27:29 GMT <minus> give it a --raw to get raw data
18:32:22 GMT <redisusr> is the next big planned redis release is 4.0 with the modules system ?
18:37:06 GMT <potatoe> thanks minus, didn't know about --raw
18:37:46 GMT <minus> i hope you're not writing bash scripts to do data manipulation in redis
18:43:31 GMT <potatoe> minus no, not really, just writing a logger that pushes logs to a redis chan so that logstash can pick it up from there
18:44:30 GMT <minus> what language? i'd imagine those exist like sand on the beach
18:45:10 GMT <potatoe> well javascript, and they do exist, but theyre either not maintained or riddled with dependencies and features that I do not want or intend to support
18:46:15 GMT <potatoe> i just want a simple interface with 3 functions for warn info and fatal that basically calls lpush/rpush and i'm done
18:48:06 GMT <redisusr> minus: you using blpop/brpop ?
18:48:35 GMT <minus> redisusr: yes
18:48:46 GMT <redisusr> minus: care to voice an opinion on an idea i have ?
18:49:39 GMT <minus> potatoe: fair enough. confirms me not wanting to do js some more too :D
18:49:48 GMT <minus> redisusr: sure
18:49:57 GMT <redisusr> potatoe: using nodejs ?
18:50:31 GMT <redisusr> minus: basically I'm thinking about creating a variant of b[lr]pop which allows you to specify a score for each key you wait on
18:50:41 GMT <potatoe> minus, redisusr, yes
18:51:16 GMT <potatoe> minus we're paying redisgreen as well so I do want to hammer their servers a bit :)
18:51:28 GMT <minus> redisusr: so b[rl]pop on a zset?
18:51:35 GMT <redisusr> so instead of having it always FIFO like it is today, think about if you have worker 1 handling 5 jobs, and worker 2 handling 10 jobs, I want when worker 1 is waiting to have *2 priority over worker 2
18:51:35 GMT <minus> for priority queues?
18:51:52 GMT <potatoe> wanted to do a protobuf based transport initially, but it seems overkill
18:51:53 GMT <redisusr> minus: no, the waiting is still on a list key, but you also give it a priority
18:51:54 GMT <minus> oh
18:52:10 GMT <JFlash> minus, you told me to look into maxlin
18:52:11 GMT <redisusr> potatoe: you can use an node.js socket with hiredis-node for handling the protocol
18:52:15 GMT <JFlash> maxlink*
18:52:38 GMT <JFlash> but most solutions use maxlinks tech behind the scenes, including the one I posted
18:53:01 GMT <minus> JFlash: not sure what you're talking about
18:54:49 GMT <minus> potatoe: protobuf/capnproto would be cool, but yes, overkill
18:55:00 GMT <potatoe> yeah capnproto!
18:55:18 GMT <potatoe> minus i considered that because we have android/ios apps out
18:55:21 GMT <minus> never worked with either of those myself
18:55:27 GMT <minus> mhm
18:55:39 GMT <minus> same actually
18:56:06 GMT <potatoe> but the devs are pretty lazy to even implement basic logging save serialized, typed logging..
18:56:59 GMT <minus> except we're using an http transport. shoved through a java/obj-c layer called from C++ code
18:57:19 GMT <potatoe> whats your aggregator?
18:57:27 GMT <minus> oh, not for logs
18:57:55 GMT <minus> never thought of piping logs from the app to a server
19:01:40 GMT <potatoe> bad practices all along here
19:01:49 GMT <potatoe> they had no choice but to pipe logs out
19:01:50 GMT <potatoe> i think
19:03:51 GMT <minus> i'll go ahead and assume bad practices happen pretty much everywhere
19:42:21 GMT <redisusr> minus: do you see a use case for it in our usage ?
19:43:05 GMT <minus> it's a very specific change, i guess you could implement it differently
19:43:53 GMT <redisusr> yes, but i guess i want to know how much is the FIFO behavior of blocking commands today annoying in other people use cases
19:44:23 GMT <minus> not at all here, i don't care which worker gets the work
19:50:29 GMT <redisusr> latest pypy supports hiredis-py :)