I guess it'd be safe to say that the read consistency could be the same as the consistency of the update. But regardless, that would be a lot better than reading a value, modifying it at the client side and then writing it back.
On Apr 3, 2013, at 7:12 PM, Edward Capriolo <edlinuxg...@gmail.com> wrote: > Counters are currently read before write, some collection operations on List > are read before write. > > > On Wed, Apr 3, 2013 at 9:59 PM, aaron morton <aa...@thelastpickle.com> wrote: > I would guess not. > >> I know this goes against keeping updates idempotent, > There are also issues with consistency. i.e. is the read local or does it > happen at the CL level ? > And it makes things go slower. > >> We currently do things like this in client code, but it would be great to >> be able to this on the server side to minimize the chance of race conditions. > Sometimes you can write the plus one into a new column and then apply the > changes in the reading client thread. > > Cheers > > ----------------- > Aaron Morton > Freelance Cassandra Consultant > New Zealand > > @aaronmorton > http://www.thelastpickle.com > > On 4/04/2013, at 12:48 AM, Drew Kutcharian <d...@venarc.com> wrote: > >> Hi Guys, >> >> Are there any short/long term plans to support UPDATE operations that >> require read-before-write, such as increment on a numeric non-counter >> column? >> i.e. >> >> UPDATE CF SET NON_COUNTER_NUMERIC_COLUMN = NON_COUNTER_NUMERIC_COLUMN + 1; >> >> UPDATE CF SET STRING_COLUMN = STRING_COLUMN + "postfix"; >> >> etc. >> >> I know this goes against keeping updates idempotent, but there are times you >> need to do these kinds of operations. We currently do things like this in >> client code, but it would be great to be able to this on the server side to >> minimize the chance of race conditions. >> >> -- Drew > >
