raw http example with scary results

Richard Bucker richard at bucker.net
Wed Feb 17 10:30:12 EST 2010


Good answer... if I were the DOCs where would I be hiding? I'm sure there
are plenty of flags etc that I might like to be familiar with?

/r

On Wed, Feb 17, 2010 at 10:23 AM, Bryan Fink <bryan at basho.com> wrote:

> On Wed, Feb 17, 2010 at 9:56 AM, Richard Bucker <richard at bucker.net>
> wrote:
> > In the online docs for the http raw... there is an example:
> >      curl http://127.0.0.1:8098/raw/example
> > and the response is supposed to look something like:
> >
> >
> {"props":{"n_val":4,"name":"example","allow_mult":false,"big_vclock":50,"chash_keyfun":{"mod":"riak_util","fun":"chash_std_keyfun"},"linkfun":{"mod":"raw_link_walker_resource","fun":"mapreduce_linkfun"},"old_vclock":86400,"small_vclock":10,"young_vclock":21600},"keys":["foo"]}
> >
> > what caught my attention was the "keys":["foo"].  If there were 10K or
> 10M
> > or more records with unique key values (possibly UUIDs)...... this
> response
> > string would be HUGE and probably unmanageable.
> > Is there a better reference for HTTP type functionality?
>
> Hi, Richard.  The raw resource accepts a "keys" parameter to help with
> this case.
>
> The default, equivalent to keys=true, will provide a response with all
> the keys in it, like you received above.
>
> keys=false will omit the "keys" field from the response.
>
> keys=chunked will provide the keylist via chunked HTTP encoding.  Each
> chunk will have a portion of the keylist, {"keys":["x","y","z",...]},
> so the client may consume it a little bit at a time.
>
> Does that solve the issue for your use case?
>
> -Bryan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.basho.com/pipermail/riak-users_lists.basho.com/attachments/20100217/f341354c/attachment.html>


More information about the riak-users mailing list