Michael Greene on IRC pointed out that you can make a case for keeping all arguments the same to a slice call, with a list of keys. This appears to be the direction Avinash was going over in
This makes sense if most of your ops are "I want to apply the same predicate multiple times to different rows." Like a relational select. This would be sufficiently general for the app I ported to Cassandra (which did after all start on a rdbms).
The alternative is to be like the batch_insert api is and for each key allow a different predicate. I can appreciate that argument from the standpoint of symmetry, but it seems that in the common case it would make life a pain, writing
predicate = ...
get_slice(table, [(key, predicate) for key in list_of_keys])
instead of just
get_slice(table, list_of_keys, predicate)
I think that Lesher's 10th law applies: "Premature optimization is the root of all evil; premature generalization is premature optimization of the feature list." Let's plan on following Avinash's lead on the multiget API, which means that I'll pull both table and key out of the path structs shown in that patch.