Thanks,
I was trying to use the number of keys as an indication of how many objects there were in a bucket but I see that is not the smartest approach. I didn't see anything that was an indication of the number of items in a bucket , is there anything if riak like this or do I need to create a map reduce job for this? This is totally off the original topic but another question I have is related to javascript Date objects. In ripple if I have a field that is a Time field it serializes to riak as a iso8601 string representation of the object. When performing a map reduce job on the bucket related to the ripple class I have if I attempt to create a javascript Date object from the string in the stored object I get an Invalid Date error. Is this just due to a limitation in the version of spider monkey being used? Thanks Rob On May 31, 2011, at 8:44 PM, Sean Cribbs wrote: > Robert, > > What Keith said is misleading -- that key cache was solely in the Ruby client > driver and not part of Riak itself. > > In Riak, deletes have two phases; in the first, so-called "tombstones" are > written to the partitions that own replicas of the key. The tombstone has > special metadata marking it as such and an empty value, but has a descendant > vector clock from the last known value. In the second phase, the tombstones > are read back from the replicas, and iff they all are tombstones (that is, > all replicas respond, and all are tombstones), a reaping command is sent such > that they will be cleared from the backend. > > In your case, what may have occurred is that the replica chosen for > key-listing did not receive the tombstone write (only 1/n_val of all > partitions are consulted for key-lists), or had not yet received the reaping > command. When you read the key again, you obviously get a "not found" because > the other replicas will resolve to a tombstone. Eventually your read requests > will invoke read-repair, updating the stale partition and causing the value > to be reaped. > > The moral of the story here is, again, don't rely on key-listings for strong > indications of cluster state. > > Sean Cribbs <[email protected]> > Developer Advocate > Basho Technologies, Inc. > http://basho.com/ > > On May 31, 2011, at 8:12 PM, Keith Bennett wrote: > >> Robert - >> >> Until a source code change a few days ago, riak would by default cache the >> keys reported to be in a bucket, so after fetching them once they would not >> be updated after deletions, additions, etc. The key is indeed gone, but the >> keys API did not report the change. >> >> If you go to the message archive at >> http://lists.basho.com/pipermail/riak-users_lists.basho.com/2011-May/thread.html, >> and search for "Riak cleint resources", you'll see the ruckus that I >> started a week and a half ago about this very subject. ;) >> >> There is an option to force the reloading of keys but I forget what it is, >> and anyway it is now gone from the current code base since the strategy was >> changed. Be warned that using the keys method is, anyway, as Sean Cribbs >> pointed out to me, in general an awful idea, and almost always should be >> avoided. This is because it's a very expensive operation -- in order to >> accomplish it, all keys in the data store need to be accessed. >> >> My guess is that testing for the exception you encountered is probably the >> best way to test for existence/absence of a key, but hopefully those more >> knowledgeable than I will enlighten us on that. >> >> - Keith >> >> On May 31, 2011, at 7:23 PM, Dingwell, Robert A. wrote: >> >>> Hi, >>> >>> When deleting a key from a bucket I'm noticing that the object associated >>> with the key is gone but the key itself is still sticking around. I loop >>> though all of the keys in a bucket and then call delete on each one, the >>> object for the key is then gone so if I try to get the object for that key >>> I get a 404 as expected. But if I look at the bucket in the browser with >>> the keys=true parameter, all of the keys are still there. Is this normal >>> and if so how do I get rid of the keys? >>> >>> Thanks_______________________________________________ >>> riak-users mailing list >>> [email protected] >>> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com >> >> >> _______________________________________________ >> riak-users mailing list >> [email protected] >> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ riak-users mailing list [email protected] http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
