Hi,
Why not convert your term to a string, and then you can do map reduce can't you?
Term to a string...
1> Term = [{one,1},{two,2},{three,3}].
[{one,1},{two,2},{three,3}]
2> String = lists:flatten(io_lib:format("~p.", [Term])).
"[{one,1},{two,2},{three,3}]."
Save "String" in riak...
Then back to a term...
3> String = "[{one,1},{two,2},{three,3}].".
"[{one,1},{two,2},{three,3}]."
4> {ok,Tok,_} = erl_scan:string(String).
5> {ok,Term} = erl_parse:parse_term(Tok).
{ok,[{one,1},{two,2},{three,3}]}
/Matt
________________________________
From: [email protected]
[mailto:[email protected]] 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://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
<[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>>
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
> [email protected]<mailto:[email protected]>
> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
_______________________________________________
riak-users mailing list
[email protected]<mailto:[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
