Bitmaps not interchangeable with strings

[newacct]

The documentation page for SETBIT has an example:

SETBIT bitmapsarestrings 2 1
SETBIT bitmapsarestrings 3 1
SETBIT bitmapsarestrings 5 1
SETBIT bitmapsarestrings 10 1
SETBIT bitmapsarestrings 11 1
SETBIT bitmapsarestrings 14 1
GET bitmapsarestrings

which should produce the string 42, but it instead produces [��sr1com.github.fppt.jedismock.datastructures.RMBitMapIsizeLbitSettLjava/util/BitSet;xr9com.github.fppt.jedismock.datastructures.StringCompatible0����psrjava.util.BitSetn��~94�![bitst[Jxpur[Jx ��u�xpL,x]

Also, when you set a string and then get the bits, it produces the wrong result:

SET foo e
GETBIT foo 0

should produce 0 (bit 0 is the most significant bit, not the least significant bit), but produces 1.

[inponomarev]

Hey @newacct , first of all, enormous thank you for submitting all the bugs for JedisMock!

This one is a known limitation, as in order to hold a value which is modified by SETBIT operations, Java's BitSet structure is used instead of String.

In Java's BitSet all the bit operations are implemented reliably and efficiently. My original hypothesis was that it is unlikely that users will be using bit-operations on data which is treated as strings at the same time(Bloom filters being the main use case for Redis' bitsets). So in JedisMock Strings and BitSets are different datatypes (similar to strings and sets) -- unlike in "real" Redis.

Could you clarify if you have a real-life use-case for this or is this just a random finding of yours?

[newacct]

We are thinking of maybe using jedis-mock in place of Redis for our unit tests once all the bugs have been ironed out, but we would disable it for unit tests that use unsupported features. There is one place in the code that tests setting bits and getting the whole bitmap out to parse, but if this is a known limitation, then that's fine; we'll just not use jedis-mock for that.

[inponomarev]

Got it. Yes it's a limitation, but not an unsurmountable one. I just thought that there are no real-world scenarios when you would like to set bits and then read the result as a meaningful string (reading it as a "data dump" which can be stored later somwhere else is supported). But yeah, as soon as there's evidence that people are doing this, we're going to fix it, although this will take a couple of months maybe.

The fix for unpack() is ready btw and is going to be released very soon.

[inponomarev]

Fixed in 1.1.6