long is not sufficient for 2i integer indices

[pallinger]

The riak interface for integer 2i does not specify an upper limit for possible index values (and I tested it with 2^1024 and it works for both exact and range queries), so having a long in the API is not sufficient.
There should be an arbitrary-precision integer used, if possible. I realise this results in an API change, but as 2.0 is not final yet, this may be bearable.

Corresponding tickets:
basho-labs/riak-data-migrator#11 (where I located the problem)
#112 (where you switched from int to long)

[broach]

Using long in the Java client user API for _int indexes was a design decision made when the change you note occurred. It is simply the most common use case and easier for most people to understand and use.

That said, the new Java client does not have this restriction. We only emphasize using long as, again, that's what most users are going to do.

If you look at the query builder in core you'll note that the parameters are all BinaryValue regardless of whether the index is an _int or _bin in Riak. The javadoc there explicitly mentions what that should be for _int indexes.

On the object side, RawIndex is provided for working directly with those bytes, and the @RiakIndex annotation now supports byte[] as well.

I just looked at the user-level API FetchIndex that sits on top of core and it actually needs some correction, but byte[] will be exposed.

[pallinger]

good news, thanks!

[broach]

I was actually working with this code and figured ... why not support it directly. It wasn't more than 30 mins of work.