Good to know that bolth options are available. :)

We don't do any version detection in CorrugatedIron and instead rely on the
developer to be relatively sane (just like you shouldn't try to send SQL
Server 2012 commands to SQL Server 2000 over an ODBC connection). Our plan
is to provide both the 1.4 counter API and the CRDT API.

We'll deprecate 1.4 counters whenever Basho does the same.

There's no information overload for me, but it is nice to see everything in
the same place.

---
Jeremiah Peschka - Founder, Brent Ozar Unlimited
MCITP: SQL Server 2008, MVP
Cloudera Certified Developer for Apache Hadoop


On Tue, Oct 22, 2013 at 3:13 PM, Russell Brown <russell.br...@mac.com>wrote:

>
> On 22 Oct 2013, at 20:24, Jeremiah Peschka <jeremiah.pesc...@gmail.com>
> wrote:
>
> > Hah! No worries at all. Thanks for the clarification. I'll rebuild.
> >
> > I wasn't sure if I needed to try to figure out (from a client
> perspective) if I needed to use the CRDT syntax for 2.0 and newer and
> RpbCounterUpdateReq for 1.4.x and earlier. Good to know that I can blindly
> proceed.
>
> Ok, this is a good question. And something we've been working on.
>
> 1.4 had counters, 2.0 has counters. Are they the same? Yes and no.
>
> In 2.0 we add bucket types. We decided that CRDTs in 2.0 should take
> advantage of bucket types. The reason being that there is no sensible way
> to merge across types (how do you merge a Map with a Set? (we thought of a
> few ways, but non were intuitive)) It comes down to the reason for CRDTs:
> no conflicts, no siblings. If we allow different types in the same bucket
> then you can create the same key with two different types, which means
> siblings types: just as complex as siblings.
>
> So, we restrict you to one CRDT type per bucket. But in 1.4 we didn't have
> this restriction. And we need to support 1.4 style counters.
>
> If you use the 1.4 API or store counters in the default (untyped) bucket
> using the 2.0 API then you're interoperable between versions.
>
> Sorry if it seems confusing. The point is that as a client developer you
> can access 1.4 counters through the 2.0 API by using the default bucket
> type OR continue support for the 1.4 API (or bolth.) Whichever you prefer.
>
> I realise this might be an information overload, so feel free to ask
> questions about anything I wasn't clear enough about.
>
> Cheers
>
> Russell
>
> >
> > ---
> > Jeremiah Peschka - Founder, Brent Ozar Unlimited
> > MCITP: SQL Server 2008, MVP
> > Cloudera Certified Developer for Apache Hadoop
> >
> >
> > On Tue, Oct 22, 2013 at 2:07 PM, Russell Brown <russell.br...@mac.com>
> wrote:
> > Yes! Sorry!
> >
> > We broke backwards compatibility during development. We merged the patch
> today[1]. The develop branch works right now. It will get into the next pre
> (or whatever the next tag is called.)
> >
> > Apologies again, it was easier for me to do the new work without
> thinking about backwards compatibility, then re-add old counters when the
> 2.0 stuff was done.
> >
> > Let me know if you have any more issues going forward, please.
> >
> > Cheers
> >
> > Russell
> >
> > [1] https://github.com/basho/riak_kv/pull/697
> > On 22 Oct 2013, at 19:56, Jeremiah Peschka <jeremiah.pesc...@gmail.com>
> wrote:
> >
> > > I'm attempting to create a counter on Riak 2.0 built from the develop
> on Sunday. When I send a counter increment message using
> RpbCounterUpdateReq, I get the following back from Riak:
> > >
> > > Riak returned an error. Code '0'. Message: Error processing incoming
> message: error:undef:[{riak_kv_counter,supported,
> > >                                                  [],[]},
> > >
> {riak_kv_pb_counter,process,
> > >                                                  2,
> > >                                                  [{file,
> > >
>  "src/riak_kv_pb_counter.erl"},
> > >                                                   {line,114}]},
> > >                                                 {riak_api_pb_server,
> > >                                                  process_message,4,
> > >                                                  [{file,
> > >
>  "src/riak_api_pb_server.erl"},
> > >                                                   {line,386}]},
> > >                                                 {riak_api_pb_server,
> > >                                                  connected,2,
> > >                                                  [{file,
> > >
>  "src/riak_api_pb_server.erl"},
> > >                                                   {line,228}]},
> > >                                                 {riak_api_pb_server,
> > >                                                  decode_buffer,2,
> > >                                                  [{file,
> > >
>  "src/riak_api_pb_server.erl"},
> > >                                                   {line,362}]},
> > >                                                 {gen_fsm,handle_msg,7,
> > >                                                  [{file,"gen_fsm.erl"},
> > >                                                   {line,505}]},
> > >
> {proc_lib,init_p_do_apply,3,
> > >
>  [{file,"proc_lib.erl"},
> > >                                                   {line,239}]}]
> > > ---
> > > Jeremiah Peschka - Founder, Brent Ozar Unlimited
> > > MCITP: SQL Server 2008, MVP
> > > Cloudera Certified Developer for Apache Hadoop
> > > _______________________________________________
> > > riak-users mailing list
> > > riak-users@lists.basho.com
> > > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
> >
> >
>
>
_______________________________________________
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com

Reply via email to