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
