7 ms·

uint_32 strikes again! And one day we'll stop using it in favor of int_64, and all unique identifiers will be string, and all will be well. I remember when Twi

uint_32 strikes again! And one day we'll stop using it in favor of int_64, and all unique identifiers will be string, and all will be well. I remember when Twitter had rolled over their tweet ID's because they were using an int type that was too short. Should have gone with variable length strings to avoid that problem.

rinon 12y ago
Var-length strings are often too slow to manipulate and store. Better choice to use a fixed but large (64-bit) integer.
- michaelgrosner2 12y ago
  Or just use a GUID.
  - deleted 12y ago
    [deleted]
  - Someone1234 12y ago
    That's 16 bytes instead of 8 bytes for a uint64 that still grants you 18,446,744,073,709,551,615 variations. Seems overkill, particularly if you actually generate GUIDs "correctly" in which case you've allocated 16 bytes but will only ever use a sub-set of them[0]. [0] https://en.wikipedia.org/wiki/Globally_unique_identifier#Algorithm https://en.wikipedia.org/wiki/Globally_unique_identifier#Alg...
    - aikah 12y ago
      Isnt mongodb using "hashes" for ids by the way? I wonder how efficient it is and why they chose to do that.
      - kevinschumacher 12y ago
        They're not hashes. There's a few things embedded in the ObjectId (from the docs - http://docs.mongodb.org/manual/reference/object-id/ http://docs.mongodb.org/manual/reference/object-id/): ObjectId is a 12-byte BSON type, constructed using: a 4-byte value representing the seconds since the Unix epoch, a 3-byte machine identifier, a 2-byte process id, and a 3-byte counter, starting with a random value. You can actually convert the _id to/from a timestamp, which lets you do cool things like never keep a timestamp field (you can convert a datetime to an ObjectId and use that for comparison).
        MichaelGG 12y ago
        If the 4 bytes are unsigned, then did they just intentionally introduce a year 2038 problem? 12 bytes is enough to just store a random value, with low chance of collisions until you've got around 100 trillion items. It confuses me why anyone would want to waste bytes of an ID on low entropy values like machine and process ID. Or any combination of high res time plus random works nicely. OTOH, Mongo's not exactly been a bastion of engineering excellence.
  - ygra 12y ago
    For counting views?
Someone1234 12y ago
> uint_32 strikes again! It isn't a uint32, it is an int32. Using strings avoids one problem but introduce a bunch of others (e.g. a string is harder to verify, therefore less secure, and therefore needs to be handled with the kiddie gloves). Checking that every character is between 0-9 and dropping all other characters is easy, cheap, and effective. Then just check it is between uint64.Min and uint64.Max, and you're done. uint32 gives them twice as much capacity (which isn't enough at this stage), they'll likely want to go with a uint64.

rinon 12y ago

Var-length strings are often too slow to manipulate and store. Better choice to use a fixed but large (64-bit) integer.

michaelgrosner2 12y ago
Or just use a GUID.
- deleted 12y ago
  [deleted]
- Someone1234 12y ago
  That's 16 bytes instead of 8 bytes for a uint64 that still grants you 18,446,744,073,709,551,615 variations. Seems overkill, particularly if you actually generate GUIDs "correctly" in which case you've allocated 16 bytes but will only ever use a sub-set of them[0]. [0] https://en.wikipedia.org/wiki/Globally_unique_identifier#Algorithm https://en.wikipedia.org/wiki/Globally_unique_identifier#Alg...
  - aikah 12y ago
    Isnt mongodb using "hashes" for ids by the way? I wonder how efficient it is and why they chose to do that.
    - kevinschumacher 12y ago
      They're not hashes. There's a few things embedded in the ObjectId (from the docs - http://docs.mongodb.org/manual/reference/object-id/ http://docs.mongodb.org/manual/reference/object-id/): ObjectId is a 12-byte BSON type, constructed using: a 4-byte value representing the seconds since the Unix epoch, a 3-byte machine identifier, a 2-byte process id, and a 3-byte counter, starting with a random value. You can actually convert the _id to/from a timestamp, which lets you do cool things like never keep a timestamp field (you can convert a datetime to an ObjectId and use that for comparison).
      - MichaelGG 12y ago
        If the 4 bytes are unsigned, then did they just intentionally introduce a year 2038 problem? 12 bytes is enough to just store a random value, with low chance of collisions until you've got around 100 trillion items. It confuses me why anyone would want to waste bytes of an ID on low entropy values like machine and process ID. Or any combination of high res time plus random works nicely. OTOH, Mongo's not exactly been a bastion of engineering excellence.
- ygra 12y ago
  For counting views?

Someone1234 12y ago

> uint_32 strikes again! It isn't a uint32, it is an int32. Using strings avoids one problem but introduce a bunch of others (e.g. a string is harder to verify, therefore less secure, and therefore needs to be handled with the kiddie gloves). Checking that every character is between 0-9 and dropping all other characters is easy, cheap, and effective. Then just check it is between uint64.Min and uint64.Max, and you're done. uint32 gives them twice as much capacity (which isn't enough at this stage), they'll likely want to go with a uint64.