Additionally, perhaps the automatically updating cache (regarding inserts/deletes) could be an optionally enabled behavior? As there are cases where it could be needlessly expensive (i.e. - high write/delete scenarios), especially when someone does not use the key listing feature. *
<http://www.loomlearning.com/> Jonathan Langevin Systems Administrator Loom Inc. Wilmington, NC: (910) 241-0433 - jlange...@loomlearning.com - www.loomlearning.com - Skype: intel352 * On Thu, May 26, 2011 at 1:23 PM, Jonathan Langevin < jlange...@loomlearning.com> wrote: > A cache seems legitimate for performance, but perhaps the cache could > additionally be maintained for inserts/deletes? > At least then the cache is still being used, but is also accurate. > > I don't know how expensive that would be though, but hopefully less > expensive than a key list reload, correct? > * > > <http://www.loomlearning.com/> > Jonathan Langevin > Systems Administrator > Loom Inc. > Wilmington, NC: (910) 241-0433 - jlange...@loomlearning.com - > www.loomlearning.com - Skype: intel352 > * > > > On Thu, May 26, 2011 at 1:18 PM, Keith Bennett < > keith.benn...@lmnsolutions.com> wrote: > >> >> On May 26, 2011, at 12:40 PM, Sean Cribbs wrote: >> >> With recent commits ( >> https://github.com/seancribbs/ripple/compare/35d7323fb0e179c8c971...da3ab71a19d194c65a7b >> ), >> it is cached until you either refresh it manually by passing :reload => true >> or a block (for streaming key lists). This was the compromise reached in >> that pull-request. >> >> All of this caching discussion glosses over the fact that you *should >> not list keys* in any real application. It really begs the question -- >> how often do you list keys in Redis, or memcached? I suspect that generally >> you don't. This isn't a relational database. (Also, how often do you >> actually do a full-table scan in MySQL? You don't if you're sane -- you use >> an index, or even LIMIT + OFFSET.) >> >> I'm tempted to remove Document::all and make Bucket#keys harder to access, >> but the balance between discouraging bad behavior and exposing available >> functionality is a hard one to strike. I don't want new developers to >> immediately use list-keys and then be discouraged from using Riak because >> it's slow; on the other hand, it *can be useful* in some circumstances. >> >> >> >> In those cases where it's useful, the developer should probably be >> responsible enough to request the key list only once; the caching behavior >> simply does this for them. I guess whether it *should* do this for them >> is the issue at hand. >> >> >> YES! Exactly! The decision to expose the functionality has been made; >> questioning whether or not this should have been done is orthogonal to >> whether or not the results should be cached, and the two should be >> considered separately. >> >> Regarding the latter, the function name represents an implied promise to >> the caller; my position is that the function's behavior is a substantial and >> surprising deviation from that implied promise. >> >> Although buckets do not *contain* key/values in the riak *implementation*, >> the bucket / key-value containment metaphor pervades the developer >> interface, evidenced by, for example, the existence of the Riak::Bucket >> class, and the structure of the URL's with which values are manipulated. In >> software products that have containment metaphors, how often do we see a >> function return a cached value rather than the up-to-date value, especially >> for products that manage shared data? >> >> All that said, I'm really torn on this issue, and the same problem applies >> to full-bucket MapReduce. Caveat emptor. >> >> >> Ok, I'll be quiet now. ;) >> >> Thanks, >> Keith >> >> >> Sean Cribbs <s...@basho.com> >> Developer Advocate >> Basho Technologies, Inc. >> http://basho.com/ >> >> On May 26, 2011, at 10:35 AM, Jonathan Langevin wrote: >> >> How long is the key list cached like that, naturally?* >> >> <http://www.loomlearning.com/> >> Jonathan Langevin >> Systems Administrator >> Loom Inc. >> Wilmington, NC: (910) 241-0433 - jlange...@loomlearning.com - >> www.loomlearning.com - Skype: intel352 >> * >> >> >> On Thu, May 26, 2011 at 10:35 AM, Sean Cribbs <s...@basho.com> wrote: >> >>> Keith, >>> >>> There was a pull-request issue out for this on the Github project ( >>> https://github.com/seancribbs/ripple/pull/168). For various reasons, the >>> list of keys is memoized in the Riak::Bucket instance. Passing :reload => >>> true to the #keys method will cause it to refresh. I like to discourage >>> list-keys, but with the memoized list you don't shoot yourself in the foot >>> as often. >>> >>> Sean Cribbs <s...@basho.com> >>> Developer Advocate >>> Basho Technologies, Inc. >>> http://basho.com/ >>> >>> On May 26, 2011, at 10:29 AM, Keith Bennett wrote: >>> >>> > All - >>> > >>> > I just started working with Riak, and am using the riak-client Ruby >>> gem. >>> > >>> > When I delete a key from a bucket, and try to fetch the value >>> associated with that key, I get a 404 error (which is reasonable). However, >>> it remains in the bucket's list of keys (i.e. the value returned by >>> bucket.keys(). Why is the key still reported to exist in the bucket? Is >>> bucket.keys cached, and therefore unaware of the deletion? Here's a >>> riak-client Ruby script and its output in irb that illustrates this: >>> > >>> > ree-1.8.7-2010.02 :001 > require 'riak' >>> > => true >>> > ree-1.8.7-2010.02 :002 > >>> > ree-1.8.7-2010.02 :003 > client = Riak::Client.new >>> > => #<Riak::Client http://127.0.0.1:8098> >>> > ree-1.8.7-2010.02 :004 > bucket = client['links'] >>> > => #<Riak::Bucket {links}> >>> > ree-1.8.7-2010.02 :005 > key = bucket.keys.first >>> > => "4000-17.xml" >>> > ree-1.8.7-2010.02 :006 > object = bucket[key] >>> > => #<Riak::RObject {links,4000-17.xml} [text/xml]:(6430 bytes)> >>> > ree-1.8.7-2010.02 :007 > object.delete >>> > => #<Riak::RObject {links,4000-17.xml} [text/xml]:(6430 bytes)> >>> > ree-1.8.7-2010.02 :008 > bucket.keys.first >>> > => "4000-17.xml" >>> > ree-1.8.7-2010.02 :009 > object = bucket[key] >>> > Riak::HTTPFailedRequest: Expected [200, 300] from Riak but received >>> 404. not found >>> > >>> > from >>> /Users/kbennett/.rvm/gems/ree-1.8.7-2010.02/gems/riak-client-0.9.4/lib/riak/client/net_http_backend.rb:55:in >>> `perform' >>> > from >>> /Users/kbennett/.rvm/rubies/ree-1.8.7-2010.02/lib/ruby/1.8/net/http.rb:1054:in >>> `request' >>> > from >>> /Users/kbennett/.rvm/rubies/ree-1.8.7-2010.02/lib/ruby/1.8/net/http.rb:2142:in >>> `reading_body' >>> > from >>> /Users/kbennett/.rvm/rubies/ree-1.8.7-2010.02/lib/ruby/1.8/net/http.rb:1053:in >>> `request' >>> > from >>> /Users/kbennett/.rvm/rubies/ree-1.8.7-2010.02/lib/ruby/1.8/net/http.rb:1037:in >>> `request' >>> > from >>> /Users/kbennett/.rvm/rubies/ree-1.8.7-2010.02/lib/ruby/1.8/net/http.rb:543:in >>> `start' >>> > from >>> /Users/kbennett/.rvm/rubies/ree-1.8.7-2010.02/lib/ruby/1.8/net/http.rb:1035:in >>> `request' >>> > from >>> /Users/kbennett/.rvm/gems/ree-1.8.7-2010.02/gems/riak-client-0.9.4/lib/riak/client/net_http_backend.rb:47:in >>> `perform' >>> > from >>> /Users/kbennett/.rvm/gems/ree-1.8.7-2010.02/gems/riak-client-0.9.4/lib/riak/client/net_http_backend.rb:46:in >>> `tap' >>> > from >>> /Users/kbennett/.rvm/gems/ree-1.8.7-2010.02/gems/riak-client-0.9.4/lib/riak/client/net_http_backend.rb:46:in >>> `perform' >>> > from >>> /Users/kbennett/.rvm/gems/ree-1.8.7-2010.02/gems/riak-client-0.9.4/lib/riak/client/http_backend/transport_methods.rb:59:in >>> `get' >>> > from >>> /Users/kbennett/.rvm/gems/ree-1.8.7-2010.02/gems/riak-client-0.9.4/lib/riak/client/http_backend.rb:72:in >>> `fetch_object' >>> > from >>> /Users/kbennett/.rvm/gems/ree-1.8.7-2010.02/gems/riak-client-0.9.4/lib/riak/bucket.rb:101:in >>> `[]' >>> > from riak-delete-failure.rb:9 >>> > >>> > Thanks, >>> > Keith >>> > >>> > >>> > >>> > _______________________________________________ >>> > riak-users mailing list >>> > riak-users@lists.basho.com >>> > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com >>> >>> >>> _______________________________________________ >>> riak-users mailing list >>> riak-users@lists.basho.com >>> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com >>> >> >> >> >> >
_______________________________________________ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
