How to store unsigned long long (uint64_t) values in a MongoDB document?

Question

I want to store numbers of type unsigned long long (uint64_t) in a MongoDB document, how do I do it?

I need to use unsigned long long because I'm using Twitter API which uses unsigned 64 bit integers https://dev.twitter.com/docs/twitter-ids-json-and-snowflake

The range of the the unsigned 64 bit integral type needs to be represended by 8 bytes and with a data range of 0 to 18,446,744,073,709,551,615.

I'm using the C++ MongoDB driver and the append member function of the BSONArrayBuilder class doesn't have an overload for unsigned long long, only for long long.

Here's the error G++ 4.7.2 spits out when I try to call arrayBuilder.append(id), with an id of type uint64_t:

MongoDB/mongo/db/../bson/bson-inl.h:342:9: error: call of overloaded ‘append(const char*&, long long unsigned int&)’ is ambiguous
MongoDB/mongo/db/../bson/bsonobjbuilder.h:167:25: note: mongo::BSONObjBuilder& mongo::BSONObjBuilder::append(const mongo::StringData&, bool)
MongoDB/mongo/db/../bson/bsonobjbuilder.h:175:25: note: virtual mongo::BSONObjBuilder& mongo::BSONObjBuilder::append(const mongo::StringData&, int)
MongoDB/mongo/db/../bson/bsonobjbuilder.h:183:25: note: mongo::BSONObjBuilder& mongo::BSONObjBuilder::append(const mongo::StringData&, unsigned int)
MongoDB/mongo/db/../bson/bsonobjbuilder.h:188:25: note: virtual mongo::BSONObjBuilder& mongo::BSONObjBuilder::append(const mongo::StringData&, long long int)
MongoDB/mongo/db/../bson/bsonobjbuilder.h:244:25: note: virtual mongo::BSONObjBuilder& mongo::BSONObjBuilder::append(const mongo::StringData&, double)
MongoDB/mongo/db/../bson/bsonobjbuilder.h:324:25: note: mongo::BSONObjBuilder& mongo::BSONObjBuilder::append(const mongo::StringData&, mongo::Date_t)

• I know that the BSON specification has int64 defined as 8 bytes (64-bit signed integer).
• I do NOT want to use a string for the ID.

Answer 1

Because MongoDB/BSON only supports signed 64-bit integers, you'll need to cast your 64-bit unsigned values to/from long long when interacting with the database.

All 64-bits are still used so you won't lose any of the available unsigned range, it will just show as a negative value in the database for those values that use the most significant bit.

Answer 2

With all due respect, IMHO the best thing you can do is to reconsider your decision not to use string for the ID since:

1. probably it is much more efficient than you ever though due to the amount of overhead of bson internals when storing 64B double which usually is 3 additional fields and field names (see 'floatApprox','top', bottom' here , here and here)

2. it is already provided as id_str by twitter API you are using for good reason

3. you are going to have real trouble casting those numbers in JS if you ever happen to use mongodb map reduce