Re: Pros/Cons to not storing JSON

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" 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 > >

Re: Pros/Cons to not storing JSON

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 e

Re: Pros/Cons to not storing JSON

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" wrote: > I still haven't had a chance to try out using BSON for a map-reduce, but in > general, parsing B

Re: Pros/Cons to not storing JSON

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,

Re: Pros/Cons to not storing JSON

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? *Jonathan Langevin Systems Administrator Loom Inc. Wilmington, NC: (910) 241-0433 - jlange...@loomlearn

Re: Pros/Cons to not storing JSON

I am also experimenting with storing objects serialized as binary data. I think this is a great way to use Riak, and you covered the pros and cons. The upcoming support for secondary indices will use metadata, so you will be able to index your binary data too: http://blog.epigent.com/2011/05/soon-

Re: Pros/Cons to not storing JSON

t; {ok,[{one,1},{two,2},{three,3}]} > > > > /Matt > > > -- > > *From:* riak-users-boun...@lists.basho.com [mailto: > riak-users-boun...@lists.basho.com] *On Behalf Of *Will Moss > *Sent:* Thursday, June 09, 2011 5:27 PM > *To:* Sean Cri

Re: Pros/Cons to not storing JSON

Cool, I've looked at BSON before for another project, and it might make sense in this case as well. Thanks! On Thu, Jun 9, 2011 at 2:26 PM, Will Moss wrote: > Hey Andrew, > > We're using BSON (bsonspec.org), because it stores binary (and other) data > types better than JSON and is also faster a

Re: Pros/Cons to not storing JSON

Ah, yes, you're right. Basically I'd have to either update all previous record docs with the new field or I'd have to have multiple record implementations to support the history of that particular record. That could be really, really ugly. Thanks Sean! On Thu, Jun 9, 2011 at 2:24 PM, Sean Cribb

RE: Pros/Cons to not storing JSON

_ From: riak-users-boun...@lists.basho.com [mailto:riak-users-boun...@lists.basho.com] On Behalf Of Will Moss Sent: Thursday, June 09, 2011 5:27 PM To: Sean Cribbs Cc: riak-users Subject: Re: Pros/Cons to not storing JSON Hey Andrew, We're using BSON (bsonspec.org<http:

Re: Pros/Cons to not storing JSON

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

Re: Pros/Cons to not storing JSON

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 B