Details
-
Bug
-
Resolution: Fixed
-
Blocker
-
2.0-beta
-
Security Level: Public
-
None
Description
When I create a document via INCR or DECR, the contents of the document end up being string representations of the number. This is great because these representations are valid JSON fragments. However, somewhere along the way this greatness is lost. By the time the ascii numerals get to the view engine, they've been base64 encoded as though they are random binary that we don't know how to handle. This is against spec. The plan was to make it so these values show up in the map function as numbers.
So a map function like this, run on a bucket where all the documents were generated by INCR, would give a leaderboard type result.
function(doc, meta)
{ emit(doc, null) }eg the sort keys in the index would be numbers like 1, 5, 88, etc. I'm attaching a screenshot where you can see that instead we get base64 encoded strings. It is possible to decode these strings and coerce them to numbers inside the map function. At one point I merged a patch that makes it so the default map function illustrated how to do that sort of thing, but it was removed for a less instructive default map function. If we fix this bug, then we wouldn't need to instruct anything in the map function anyway... so let's fix the bug.
Attachments
Issue Links
- relates to
-
MB-15129 view engine treats counters as binary.
- Closed