Riak Client Resources, Deleting a Key Doesn't Remove it from bucket.keys

Sean Cribbs sean at basho.com
Thu May 26 15:12:59 EDT 2011

> 1)  I would rather be hit by a large cost that I can see and feel instead of trying to run down hidden keys from a stale cache (reflect on chasing memory corruptions...)

I think that's fair; it emphasizes the fact that if you shouldn't use it once, you shouldn't be using it twice! (or at least manage the list yourself and all that entails)

> 2)  Make a riak-configuration value to enable or disable it.  You have to explicitly go turn it on to use it.   It's more of an "if you turn this on, you implicitly accept the penalties and issues surrounding actually using it."

A configuration variable isn't necessary, at least from the HTTP interface, you have to explicitly request keys. List-keys on PBC is a separate request.  Either way you really need to explicitly call it (except in the case of Document::all, which is sort of a separate issue altogether).  The question is more how the higher-level client should behave; we're not yet prepared to remove it entirely from Riak.

In speaking with Kyle and some of the other committers, we've come to a new decision:

1) The cached key-list will be removed altogether.
2) We may introduce a console warning when you invoke list-keys, with the option to turn it off if you set a really verbose and annoying configuration option in the client. Something like :yes_i_really_really_want_to_list_keys_dont_warn_me_ever => true.  The warning would be active for Client#buckets as well as Bucket#keys.

Sean Cribbs <sean at basho.com>
Developer Advocate
Basho Technologies, Inc.

More information about the riak-users mailing list