Dmitry, On 4 August 2010 01:09, Dmitry Demeshchuk <[email protected]> wrote: > 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.
It has advantages if the database understands certain datatypes. For, instance I don't need to round-trip the entire value to and from the client just to append an item to it if for example, it's a list. This stuff *really* matters when you have performance constraints. > 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. Should, in what context? I'm talking about creating something new here, on top of riak_core. My questions are about the feasibility of whether I could extend riak_core to be able to handle these situations. If the client _should_ be handling the data with higher-level semantics (if for example, it's simply not possible to impose other semantics on the values other than delete / replace in the current incarnation of riak_core) then please explain why that's necessary. > > 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. > And the multi-values and vector clocks are what I want to preserve in system that has richer semantics on values (i.e. the values are typed up to client API level). All I am interested in, is if this is possible to build on top of a vanilla riak_core. Perhaps a better question is this: "Is the fundamental operation of riak_core coupled to the fact that values are opaque blobs?". I'm hoping that the answer is 'no' and this seems like it might be the answer, given that you said Riak values can be any Erlang term. It's just that that's not exposed through client APIs, so I am wondering at what level of the stack that ceases to be the case. > On Tue, Aug 3, 2010 at 6:15 PM, James Sadler <[email protected]> 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 <[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 >> > > > > -- > Best regards, > Dmitry Demeshchuk > -- James _______________________________________________ riak-users mailing list [email protected] http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
