Ah, gotcha. I'll have to stick with JSON then, thanks :-)
- Jon Langevin -- sent from my Android phone On Jun 14, 2011 12:58 PM, "Will Moss" <wm...@bu.mp> wrote: > You wouldn't be able to do it in Javascript, you'd have to use Erlang. Then, > you'd just import the BSON library to parse the values. > > Will > > > On Tue, Jun 14, 2011 at 9:50 AM, Jonathan Langevin < > jlange...@loomlearning.com> wrote: > >> How would we tell the m/r that the data type is BSON? Does the js engine >> already have BSON support included? >> >> - Jon Langevin -- sent from my Android phone >> On Jun 14, 2011 12:47 PM, "Will Moss" <wm...@bu.mp> wrote: >> > I still haven't had a chance to try out using BSON for a map-reduce, but >> in >> > general, parsing BSON is faster than parsing JSON and I'd imagine that's >> > true in Erlang as well. So, I'd assume using BSON is faster, but you know >> > what they say about assumptions... >> > >> > Will >> > >> > >> > On Tue, Jun 14, 2011 at 9:40 AM, Jonathan Langevin < >> > jlange...@loomlearning.com> wrote: >> > >> >> Would the Riak standard map/reduce be able to deal with BSON properly, >> or >> >> would map/reduce functionality be less efficient than if it were >> inspecting >> >> JSON objects? >> >> >> >> <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, Jun 9, 2011 at 5:26 PM, Will Moss <wm...@bu.mp> wrote: >> >> >> >>> Hey Andrew, >> >>> >> >>> We're using BSON (bsonspec.org), because it stores binary (and other) >> >>> data types better than JSON and is also faster and more wire efficient >> >>> (sounds like about the same reasons you're considering leaving JSON). >> There >> >>> are also libraries to parse BSON it in just about every language. >> >>> >> >>> I haven't tried using it in a Erlang map-reduce yet (we don't do >> >>> map-reduces for any of our production work), but there is a library out >> >>> there so it shouldn't be too hard. >> >>> >> >>> Will >> >>> >> >>> >> >>> On Thu, Jun 9, 2011 at 2:24 PM, Sean Cribbs <s...@basho.com> wrote: >> >>> >> >>>> Andrew, >> >>>> >> >>>> I think you're on the right track here, but I might add that you'll >> want >> >>>> to have upgrade paths available if you're using records -- that is, >> version >> >>>> them -- so that you can evolve their structure over time. That could >> be a >> >>>> little hairy unless done carefully. >> >>>> >> >>>> That said, you could use BERT as the serialization format, making >> >>>> implementing JavaScript M/R functions a little easier, and interop >> with >> >>>> other languages. >> >>>> >> >>>> Sean Cribbs <s...@basho.com> >> >>>> Developer Advocate >> >>>> Basho Technologies, Inc. >> >>>> http://basho.com/ >> >>>> >> >>>> On Jun 9, 2011, at 5:14 PM, Andrew Berman wrote: >> >>>> >> >>>> > I am using Riak using the Erlang Client API (PB) and I was storing >> my >> >>>> documents as JSON and then converting them to records when I pull them >> out >> >>>> of Riak, but I got to thinking that maybe this isn't the greatest >> approach. >> >>>> I'm thinking that maybe it's better to store documents just as the >> record >> >>>> itself (Erlang binary) and then just converting the binary back to the >> >>>> record when I pull them from Riak. I was wondering what the pros/cons >> are >> >>>> to this approach. Here's my list so far: >> >>>> > >> >>>> > Pros: >> >>>> > >> >>>> > Native Erlang is stored, so less time to convert to the record >> >>>> > Better support for nested records >> >>>> > Smaller storage requirements and hence faster on the wire (?) >> >>>> > >> >>>> > Cons: >> >>>> > >> >>>> > Not readable through Rekon (or other utils) without modification >> >>>> > Can't use standard M/R functions which analyze the document (have to >> >>>> write all custom functions using Erlang) >> >>>> > Not portable across languages >> >>>> > >> >>>> > Thanks, >> >>>> > >> >>>> > Andrew >> >>>> > _______________________________________________ >> >>>> > 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 >> >>> >> >>> >> >> >>
_______________________________________________ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
