Adding support for CAS

[Peter Lin]

I started looking into adding Thrift CAS support. A couple of thoughts. Since CAS can be used for both insert and update, one way would be to add a new method to Mutator interface

MutationResult executeWithCAS();

Does it make sense to also add CAS specific methods for incrementing/decrementing counters


peter

[Patricio Echagüe]

I think it makes sense.

Sent from my Nexus 4.

--
You received this message because you are subscribed to the Google Groups "hector-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hector-users...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Nate McCall]

For consistency yeah.

Honestly, I want to say "no" solely because if people use CAS +
counters with any regularity, they will melt their cluster.

Either way, thanks, Peter!

[Peter Lin]

LOL

By "melt their cluster" you mean volcanic ash spews from their data center and swallows the ISP in a pit of despair.

Sounds like executeWithCAS is desirable, but counter specific CAS "use at your own risk" until 2.1 comes out and improves counters

[Nate McCall]

Ha - yeah, effectively.

Long ago (2010!) Ran and I debated some things like leaving out
getCount and capping Slice sizes to protect folks from a good
foot-shooting. Back then, we got a lot of the same "why's it slow"
questions about these two things specifically as there was far less
documentation around.

We eventually decided to support everything so it would match the
functionality of the thrift API itself as well as matching API
defaults (like 100 for slices).

I just got really good with the "canned response" feature in Gmail :)

[Peter Lin]

I'll start with adding executeWithCAS and get that working.

if others want increment/decrement specific CAS, we can always add it later.

[Peter Lin]

looking at the CAS method, looks like it expects mutations to 1 row.

public CASResult cas(ByteBuffer key, String column_family, List<Column> expected, List<Column> updates, ConsistencyLevel serial_consistency_level, ConsistencyLevel commit_consistency_level) throws InvalidRequestException, UnavailableException, TimedOutException, org.apache.thrift.TException

I could have the implementation check to see if the pending mutation list only has 1 key. If it has more than 1 key, throw an exception so the user knows they're doing something that's not allowed or recommended.

[Peter Lin]

I worked on the implementation a bit today and couple things came to mind.

CAS takes 2 lists of columns: expected and update

It doesn't use Thrift Mutation class. I'm starting to ask myself " do we need a separate class to encapsulate CAS operation instead?"

Currently, our BatchMutation uses thrift Mutation class and doesn't directly handle List<Column>. From an usability perspective, maybe a new CASMutation class would be more user friendly. Mutator class would have additional methods like addCASInsertion() and the implementation would use CASMutation. I could convert the Mutation list to List<Column> but that kind of feels ugly.

what do people think?

peter

[Nate McCall]

That's a good point - it's going to be difficult to wedge into
BatchMutation regardless.

Creating something new is probably the best way to go so it's clear
that this is something different.

[Peter Lin]

I spent some time on CAS this weekend. The only thing remaining is handling CASResult. Unlike regular mutation, it does need to return information to the user. Right now I'm thinking of making a subclass of MutationResultImpl to hold the CASResult.

The other option is a separate concrete class that doesn't extend MutationResultImpl, but I don't think that buys us anything.