Home | Forums | Couchbase | Couchbase Server 2.0

Couchbase view not rerurning all values.

2 replies [Last post]
Sat, 07/14/2012 - 00:25
SkeLLLa
Offline
Joined: 06/22/2012
Groups: None

I hava a database, that contains chat messages between users (1 message copy per user: 1 message for sender and one for recepient). Running Couchbase server 2.0 dev preview 4 cluster with 2 machines (1 linux and 1 windows). All values stored in utf-8 encoding.

I use such map function to retreive messages betwen users:

function (doc) {
  if (doc.type == "msg"){
    emit([doc.OwnerId, doc.SndrId, doc.Date], {"Date":doc.Date, "OwnerId":doc.OwnerId, "RcptId":doc.RcptId, "SndrId":doc.SndrId, "Text":doc.Text, "Unread":doc.Unread, "id": doc.id, "type":doc.type});
    emit([doc.OwnerId, doc.RcptId, doc.Date], {"Date":doc.Date, "OwnerId":doc.OwnerId, "RcptId":doc.RcptId, "SndrId":doc.SndrId, "Text":doc.Text, "Unread":doc.Unread, "id": doc.id, "type":doc.type});
  }
}

So if I try to receive some messages (ordered decending by date) and use such startkey & endkey:
startkey=[1,2,{}]
endkey=[1,2,0]

I get not all messages. To get all messages I need to use
startkey=[1,2,{}]
endkey=[1,2]

Can anyone explain why in first case I haven't received all docs?

For more info and doc examples see http://stackoverflow.com/questions/11473147/couchbase-couchdb-strange-vi....

Top
Sat, 07/14/2012 - 16:58
FilipeManana
Offline
Joined: 04/02/2012
Groups: None

Hello,

Looking at your stackoverflow post, where you show some rows, I see that your doc.Date field values are 64 bits integers.
It's an unfortunate bug in Erlang OTP R14B03 (and all prior versions) on 64 bits platforms. DP4 shipped OTP R14B03, but the most recent 2.0 builds we offer fortunately ship R14B04, which has that bug fixed.

If you're interested in the technical details, here's the Erlang OTP commit that fixes and explains the issue:

https://github.com/erlang/otp/commit/03d8c2877342d5ed57596330a61ec037409...

In short, while doing collation, we use OTP's enif_compare function to compare your dates with 0, which implies doing a subtraction and enif_compare returns that subtraction casted to a 32bits integer, even when the difference is not representable with 32bits, producing incorrect values. This affected 64 bits environments only.
I debugged and submitted that fix upstream myself.

Hope it helps.

cheers

Top
Mon, 07/16/2012 - 03:25
SkeLLLa
Offline
Joined: 06/22/2012
Groups: None

Yeah, I use 64bits integers to store dates (forgot to mention this). Now I use my second variant without zero date. I'll wait until recent 2.0 builds came for windows platform to update my cluster and check this issue.

You can also repost your answer to stackoverflow.

Thanks for answer.

Top