gistfile1.txt

08:41 <beat> is it possible to link walk on a defined set of keys? 
without doing iteration over the keys on the application-side 

08:42 <roidrage> beat: yes, you can feed them into a 
map/reduce request, add a link walking phase, and have the 
map phase return the values from the link walk 

08:42 <beat> awesomesauce :D gotta try it! 

08:44 <seancribbs> beat: internally that's how link-walking works. 

08:44 <seancribbs> for returning intermediate phases, it issues 
multiple mapreds 

08:45 <beat> hmm a chain of m/r basically 

08:45 <seancribbs> yep 

08:45 <beat> great. I already noticed that there's support for 
link phase on ripple's m/r object, so I should have rtfm 

08:47 russelldb joined 

08:48 <beat> also, I know there are some issues with having too 
much links, is this limitation by design (and planned) or is there a 
plan to overcome the limitations? I know the problem with http 
(big headers) can be overcome by using pbc, but what about 
decreased performance when there are too many links? 

08:48 <beat> that english came out ugly as hell lol, portuguesenglish :\ 

08:50 <roidrage> beat: the boundary is more in the increased data size in general, not the specific number of links 

08:50 <roidrage> as always: it depends™ 

08:53 <beat> roidrage: So, adding more nodes allows me to overcome the problem? 

08:54 <roidrage> beat: no, because the links are still associated 
with one object, the more links you add, the larger this single object will be 

08:55 <seancribbs> beat: one workaround is to store the links in a 
separate object, especially if you'll be mutating them separately 

08:55 <seancribbs> as long as the two have the same key, it's easy 
to reason about 

08:55 <seancribbs> bah, brb 

08:56 <beat> the object that holds the links will eventually become 
bigger and bigger 

08:56 <hoodoos> i wonderif I can store pdf in riak? and get it with 
application/pdf content type 

08:57 <beat> wouldn't we have the same problem? 

08:57 <seancribbs> beat: yes, there is that. 

08:57 <roidrage> hoodoos: sure you can. depending on the size it may be worth looking into luwak for that 

08:57 <hoodoos> noo, it's sooo small, like 25 kylobytes 

08:57 <beat> we could split it into different objects but that's cumbersome 

08:58 <roidrage> beat: how many links are you aiming for? 

08:58 <seancribbs> beat: you can also use luwak as roidrage 
mentioned. but you'll need your own link-processing functions 

08:58 <roidrage> hoodoos: that should be totally fine 

08:59 <beat> seancribbs: it could go over 1000 links in some cases 

08:59 <seancribbs> beat: should you really be using a graph db for this? 

09:00 <beat> not sure 

09:00 <beat> i could work it around 

09:00 <seancribbs> no reason why you can't do both 

09:00 <seancribbs> just sayin' 

09:00 <beat> having links would be a nice thing 

09:00 <beat> a good way to model things 

09:01 <beat> but it's not like i'll be doing intense 
"graph"-like operations 

09:01 <seancribbs> links were originally an answer to 
the typical "relational" query where you join across multiple tables. 

09:01 <seancribbs> not the extreme fanout that graphs give you 

09:01 <beat> yup that's mainly what I want it for 

09:01 <seancribbs> 1000 seems like a lot though 

09:02 <beat> (the first one, joins) 

09:02 <beat> links are also good for self-referential entities, 
which I have a lot 

09:03 <seancribbs> aha, so you really are doing a graphy thing 

09:03 <seancribbs> not saying that you shouldn't use riak. but links are intentionally limiting 

09:03 <beat> yes, some objects have an hierarchy 

09:11 danoyoung joined 

09:11 <beat> seancribbs: what's the "average highest" amount of 
links that I should be able to use per object? 

09:11 <beat> if there is such a thing 

09:14 <seancribbs> if you're using HTTP, there's a hard limit, 
but it's really high.