Ah, yeah that makes sense now. Presumably an IllegalArgumentException?
When a batch of conditional mutations is passed to the conditional writer, can not throw an exception. Need to know the status of each one. I am thinking of adding something to the status enum, just not sure what to call the enum.
Can you put it up on the gitchubs or bitbucket?
Sean Busbey, I like the Cell proposal. I also agree w/ your arguments for not using it.
This might just be my bias against Object creation in Java.
Thats a good bias to have (if only there were some safe way to allocate objects on the stack). Normally I would agree w/ this, but I am thinking in this case the operation (lock row on server side, read, maybe update) is so expensive that it possibly dwarfs this concern. However in the case where data is cached in the tserver its not as expensive.
the unwrapped version has the advantage of looking more like other methods used in Mutation.
Agreed, consistency is very important. For me this is the main argument for not using the Cell+Test design. Changing the API for mutation is not really an option.
William Slacum I just fully understood the significance of your earlier comment w.r.t API. Users will be able to do any check they like using iterators. Therefore we do not need to anticipate future mutation conditions besides equality and presence.