James, What mechanism are you trying to implement? Generally, it's not a good way to let your database operate the format of your data.
For example, if you want to store some lists of data and append new items to them or remove existing ones, you won't need Riak to check data types itself. All such checks should be handled by your Erlang code. But if you are speaking of Riak data consistency, it has two major features for that: multi-values and vector-clocks. The first feature guarantees that you won't lose any important data and will be able to compare your old and new values and decide their consistency manually. And the second one offers very reliable automatic consistency checks that can solve consistency problems in many cases. On Tue, Aug 3, 2010 at 6:15 PM, James Sadler <freshto...@gmail.com> wrote: > 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 <demeshc...@gmail.com> 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 <freshto...@gmail.com> 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 >>> riak-users@lists.basho.com >>> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com >>> >> >> >> >> -- >> Best regards, >> Dmitry Demeshchuk >> > > > > -- > James > -- Best regards, Dmitry Demeshchuk _______________________________________________ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
