That would work too. You could always introduce a new method on the interface that can accommodate a long and deprecate the existing one. That would not break backward compatibility. I doubt the database would break since it already supports 64 bit indexes.
Converting the long to its hex equivalent would cause range queries on the bin index to fail, which is why I needed the feature to begin with. However building on your idea of using a bin index on the string and from this riak help page [1], a bin index built on a string representation of a long number should also retain the capability to run range queries using - buckets/mybucket/index/field1_bin/val2/val4. Thank you for your answer Jeremiah. I'll give this a shot sometime and switch to native 64 bit indexes when they become available. [1] - http://docs.basho.com/riak/1.2.0/cookbooks/Secondary-Indexes---Configuration/ Thanks -Deepak On Sun, Dec 9, 2012 at 7:58 PM, Jeremiah Peschka <jeremiah.pesc...@gmail.com > wrote: > If you need an index on a 64-bit value, you can get creative and store the > 64-bit number as the hex representation of your 64-bit value in a binary > index. Seems to me that a bit of lateral thinking is easier than a breaking > change in either a database client or, worse, a database itself. > > Example: > > 1619587083804677205 becomes the string 0x1679EDDF2CFD1455. > > Using the powers of sorting, everything works out in the end.6 > > > > On Sunday, December 9, 2012, Deepak Balasubramanyam wrote: > >> Bumping this thread back up. Can someone from Basho take a shot at this ? >> >> Thanks >> -Deepak >> >> >> On Wed, Dec 5, 2012 at 6:10 PM, Deepak Balasubramanyam < >> deepak.b...@gmail.com> wrote: >> >>> Hi folks, >>> >>> I have a query regarding riak indexes. My current understanding is that >>> riak cannot index numbers whose representation needs more than 32 bits. >>> There is an issue on the basho repo to address this - >>> https://github.com/basho/riak-java-client/issues/112 . Do you have any >>> idea when it will be fixed ? >>> >>> I've mentioned a way to work around this problem on a comment on the >>> issue. The work-around would not be efficient since JS code would have to >>> go through N rows to drop ones that do not fit a particular criteria on the >>> number. If there is a better solution to the problem, I'd like to hear your >>> thoughts on that also. >>> >>> Thank you for your time. >>> -Deepak >>> >> >> > > -- > --- > Jeremiah Peschka > Founder, Brent Ozar Unlimited > Microsoft SQL Server MVP > > > _______________________________________________ > riak-users mailing list > riak-users@lists.basho.com > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com > >
_______________________________________________ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
