如何在MongoDB文档中存储unsigned long long(uint64_t)值?

bit*_*tek 6 c++ twitter mongodb mongodb-query

我想在MongoDB文档中存储unsigned long long(uint64_t)类型的数字,我该怎么做?

我需要使用unsigned long long,因为我使用的是使用无符号64位整数的Twitter API https://dev.twitter.com/docs/twitter-ids-json-and-snowflake

无符号64位整数类型的范围需要用8个字节表示,数据范围为0到18,446,744,073,709,551,615.

我正在使用C++ MongoDB驱动程序,并且BSONArrayBuilder类的append成员函数没有对unsigned long long的重载,只有很长时间.

当我尝试调用arrayBuilder.append(id)时,错误G ++ 4.7.2吐出,id为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)
Run Code Online (Sandbox Code Playgroud)
  • 我知道BSON规范将int64定义为8字节(64位有符号整数).
  • 我不想为ID使用字符串.

Joh*_*yHK 11

由于MongoDB/BSON仅支持带符号的64位整数,因此long long在与数据库交互时,需要将64位无符号值转换为/从中.

仍然使用所有64位,因此您不会丢失任何可用的无符号范围,它将在数据库中显示为使用最高有效位的值的负值.

  • @BadDesign这些值在转换时(以及在DB中)将变为负数,但只要在读回时将它们转换回`uint64_t`就可以了. (3认同)

nic*_*lon 1

恕我直言,您能做的最好的事情就是重新考虑您不使用字符串作为 ID 的决定,因为:

  1. 可能它比你以前的效率要高得多,因为存储 64B double 时 bson 内部的开销量通常是 3 个附加字段和字段名称(请参阅“floatApprox”,“top”,“bottom”此处此处此处

  2. 您使用的 Twitter API 已将其作为 id_str 提供,这是有充分理由的

  3. 如果你碰巧使用了 mongodb map reduce,那么在 JS 中转换这些数字将会遇到真正的麻烦