On Thu, Jun 5, 2008 at 12:48 PM, Aaron Stone <<a href="mailto:aaron@serendipity.cx">aaron@serendipity.cx</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I'll note that you got exactly the behavior as advertised:</blockquote><div><br>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.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> the data did not match the format and was treated as 0, so it's really not an edge case, per se.<br>
<br>
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.</blockquote><div><br>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.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">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.<br><font color="#888888">
</font></blockquote><div><br>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. :-) <br>
<br>But let's do something .... the current behavior is strange for no good reason. I doubt anybody's relying on it.<br><br>- Brad<br></div></div><br><br>