Great, thx :)
On 2014年3月5日 at 上午12:27:37, Sam Elliott (sam.elli...@basho.com) wrote:
> Yes, batch your updates, it'll be much more efficient that way.
>
> Do not try to decode the `context` object. Use it as an opaque value, as the
> data it holds
> could change without warning.
>
> Sam
>
Also one more question, what exactly is the context object? how big it is? is
that something like vclock ? or a encoded full object(which might be really big
if sending background)
On 2014年3月5日 at 上午1:31:23, Russell Brown (russell.br...@me.com) wrote:
> And you only need to send the context obj
Great, Thanks XD
On 2014年3月4日 at 下午11:07:16, Sean Cribbs (s...@basho.com) wrote:
> Yes, we will be investigating that.
>
>
> On Tue, Mar 4, 2014 at 9:03 AM, EmiNarcissus wrote:
>
> >
> > Hi Sean,
> >
> >
> > Thanks for the clarification. So after 2.1 it might add those capabilities
> > ?
>
Hi Sean,
Thanks for the clarification. So after 2.1 it might add those capabilities ?
On 2014年3月4日 at 下午11:02:53, Sean Cribbs (s...@basho.com) wrote:
> Hi Tim,
>
> We punted on sub-type queries for 2.0. We intend to address them in 2.1, so
> yes you must fetch the entire set or map in order to
Hi Sean,
Thanks very much, that’s very helpful. Anyways, I’ve noticed in update_dt
function they are preferred to apply a context dict, which in the mail list
described as a encoded version of original object(dict,set, so to say on a
single update action, each time a new record is being added/
And you only need to send the context object if you’re removing things, so if
you can partition your work between adds and removes, you can have more
efficient adds.
On 4 Mar 2014, at 16:27, Sam Elliott wrote:
> Yes, batch your updates, it'll be much more efficient that way.
>
> Do not try to
Yes, batch your updates, it'll be much more efficient that way.
Do not try to decode the `context` object. Use it as an opaque value, as the
data it holds could change without warning.
Sam
--
Sam Elliott
Engineer
sam.elli...@basho.com
--
On Tuesday, 4 March 2014 at 10:22AM, EmiNarcissus w
To answer another thing brought up in your message:
When you say "big enough" set sizes of 10k, be very careful. Riak Data Types
should not be larger than you would make a normal Riak Object. There's more
guidance in this thread:
http://lists.basho.com/pipermail/riak-users_lists.basho.com/2014
Yes, we will be investigating that.
On Tue, Mar 4, 2014 at 9:03 AM, EmiNarcissus wrote:
>
> Hi Sean,
>
>
> Thanks for the clarification. So after 2.1 it might add those capabilities
> ?
>
> On 2014年3月4日 at 下午11:02:53, Sean Cribbs (s...@basho.com) wrote:
> > Hi Tim,
> >
> > We punted on sub-type
Hi Tim,
We punted on sub-type queries for 2.0. We intend to address them in 2.1, so
yes you must fetch the entire set or map in order to find out things like
membership and cardinality.
On Tue, Mar 4, 2014 at 8:01 AM, EmiNarcissus wrote:
> Hi,
>
> I’m now porting the riak 2.0 driver for twiste
Hi,
I’m now porting the riak 2.0 driver for twisted, it works beautifully now with
what Yokozuna provides, also have a great back-port ability,really appreciate
everything what this team have brought us XD. But because it still in lacks of
document, I must read the implementation both from ruby
11 matches
Mail list logo
