Good point, Eric. This is the primary reason that Ripple switched to ISO 8601 format as the default; also that other languages will often use ISO 8601, whereas RFC 822 is less common.
Sean Cribbs <[email protected]> Developer Advocate Basho Technologies, Inc. http://basho.com/ On Jun 1, 2011, at 10:33 AM, Eric Moritz wrote: > Depending on what you need the date for, you may be able to skip the > parsing step. If you're using it for sorting or comparison, ISO8601 > can be compared lexicographically and usually no parsing is needed, > "earlier_isodate < later_isodate" will be true in Javascript even > though they're strings. I just wanted to point that out in case you > over looked this property of ISO8061 formatted strings. > > Eric. > > > On Wed, Jun 1, 2011 at 9:45 AM, Sean Cribbs <[email protected]> wrote: >> Rob, >> >> Yes, you can use the provided iso8601.js file (only generated for you in a >> Rails 3 project, unfortunately, but you can grab it from inside the gem or >> on github) to parse ISO8601 Dates. You'll need to set the js_source_dir in >> app.config to point to the directory where this lives. >> >> If we upgrade erlang_js to a later version of Spidermonkey in the future, >> the iso8601.js file will no longer be needed (1.8.5 supports ISO8601). You >> can also choose to use RFC822-style dates by setting Ripple.date_format = >> :rfc822. >> >> Sean Cribbs <[email protected]> >> Developer Advocate >> Basho Technologies, Inc. >> http://basho.com/ >> >> On Jun 1, 2011, at 9:37 AM, Dingwell, Robert A. wrote: >> >>> >>> >>> 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 >>>> >>> >> >> >> _______________________________________________ >> 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 _______________________________________________ riak-users mailing list [email protected] http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
