Hi Dmitry, Being able to represent any Erlang term is a good start.
Which leads me to Riak's conflict resolution. Does this part of Riak understand the data types or does it just present the N alternative values for a key to the client when there is a conflict? There is potential for some semi-automated merging to be done server-side in the case where values have richer semantics. I suspect that it would depend on the application, and the client would need to tell Riak it's OK to perform an automatic merge on write. On 3 August 2010 23:59, Dmitry Demeshchuk <[email protected]> wrote: > Hi, James. > > Actually, Riak can store all Erlang terms: lists, tuples, numbers, > binaries, etc. > > But if you use, for example, PHP or Python, you can just use your own > serialization format. So there are no problems here for any other > languages as well. > > On Tue, Aug 3, 2010 at 5:47 PM, James Sadler <[email protected]> wrote: >> Hi guys, >> >> Is there any plan for supporting more than opaque blobs as values in >> the future? For example, lists, sets, hashes etc, including >> server-side support for operating on those data-types? >> >> In the meantime, I am curious about the feasibility of putting >> riak_core in front of Redis, and supporting a richer API in the layers >> above (which I suspect would need to be heavily modified to support >> additional value manipulation functionality). >> >> Also, is anyone aware of anyone attempting such a project? >> >> Cheers, >> >> -- >> James >> >> _______________________________________________ >> riak-users mailing list >> [email protected] >> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com >> > > > > -- > Best regards, > Dmitry Demeshchuk > -- James _______________________________________________ riak-users mailing list [email protected] http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
