> > 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 <[email protected]> Developer Advocate Basho Technologies, Inc. http://basho.com/ _______________________________________________ riak-users mailing list [email protected] http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
