The cmp() function used to compare btree keys was using the
trick of comparing unsigned values by coercing the result
of subtraction to a signed type. This is fine as long as
the range of differences never actually exceeds the limits
of the signed type. For instance, with int64, as long as
the magnitude of the difference is under 2^63 or so, it
works reasonably well.
Plain int, however, can be a 32-bit type, at which point
the magnitude of difference needed to break it is only
2^31 or so.
Subtraction and type conversion is enough cheaper than
branches that this is worth preserving, but it's worth
preserving by switching to an explicit int64 for the
operation and return type. This will not actually affect
performance except for people using the btree code on
32-bit machines, so it probably won't ever matter.
Which may also be true of the potential wrong answers,
but "might be slower" is a better risk than "might
crash".
Long ago, the maintainers of gorilla/mux concluded that
it was a "wontfix" to return StatusMethodNotAllowed instead
of StatusNotFound for a method mismatch. Pilosa had a
workaround for this for the most common case (GET requests
to /index/{index}/query), and a TODO to address the other
cases.
While browsing the go-pilosa client code, I noticed that there
is a test for roaring import support which relies on getting
StatusMethodNotAllowed. But how can this work, if gorilla/mux
doesn't do that?
Answer: They started doing it in mid-2017, apparently:
https://github.com/gorilla/mux/issues/271
Dropping this code changes the exact text of the message
produced for that one case, but not the status code,
and makes the behavior less confusing.
This commit adds the ability to remove an 'available shard'
from the shard cache. This does not affect shards known to be
available because of local data.
