On Thu, Jun 5, 2008 at 12:48 PM, Aaron Stone <[EMAIL PROTECTED]> wrote:
> I'll note that you got exactly the behavior as advertised: Yes, I know. I cited the protocol doc in my email. And I blame only myself for even specifying that behavior in the first place: it was out of laziness just because stroull()'s API kinda sucks. the data did not match the format and was treated as 0, so it's really not > an edge case, per se. > > I'd rather see us start to look at the binary protocol's field for > specifying the data type of a value, and specify that incr/decr only > function if the data type is integer. As Dustin says, this is kinda irrelevant since we don't have a "Create counter" RPC which initializes a counter. We have to support vivifying a counter from a string at some point, and will probably forever. In either case, adding a new error code, such as your proposed NOT_NUMBER, > makes more sense to me than NOT_FOUND (or more generically, following my > proposal of starting to use the data type field, WRONG_DATA_TYPE). Either > new error will require client changes, whereas NOT_FOUND will work with > current clients now. It's just that it's an actual corner case hack, instead > of a perceived one, and is certainly a violation of the principle of least > surprise when INCR returns NOT_FOUND, but GET returns your integer, neatly > unserialized for you by your client library. > Yeah, pros and cons both ways. Another proposal, just for fun: we could return NOT_FOUND (pro: no change to clients!) when it's not a number, and _also_ delete the value. So no "get" surprises later. :-) But let's do something .... the current behavior is strange for no good reason. I doubt anybody's relying on it. - Brad
