what will happen to ObjectIDs in year 2038 ?
Shimon Doodkin
http://www.mongodb.org/display/DOCS/Object+IDs#ObjectIDs-DocumentTimestamps
:
_id : ObjectId( "47cc67093475061e3d95369d" )
BSON ObjectID Specification
A BSON ObjectID is a 12-byte value consisting of a 4-byte timestamp
(seconds since epoch), a 3-byte machine id, a 2-byte process id, and a
3-byte counter. Note that the timestamp and counter fields must be
stored big endian unlike the rest of BSON. This is because they are
compared byte-by-byte and we want to ensure a mostly increasing order.
Here's the schema:
bytes: | 0 1 2 3 | _ 4 _ 5 _6 | 7 8 | 9 10 11
name: | time_ _ | _ machine | pid | inc
Eliot Horowitz
until 2007, and so can rollover till 2075 safely.
At that point, we'll have to change it or add a new type.
> --
> You received this message because you are subscribed to the Google Groups "mongodb-user" group.
> To post to this group, send email to mongod...@googlegroups.com.
> To unsubscribe from this group, send email to mongodb-user...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/mongodb-user?hl=en.
>
>
Chuck Remes
On Jul 10, 2010, at 8:45 PM, Eliot Horowitz wrote:
> Well - they're safe until 2075 or so, since no object ids were created
> until 2007, and so can rollover till 2075 safely.
>
> At that point, we'll have to change it or add a new type.
So you have defined the epoch as sometime in 2007? Sounds like you have modified the definition of the type already. Anyone using it as seconds from UNIX epoch is going to come up with the wrong answer.
??
cr
Eliot Horowitz
It says to use the current time as the first 4 bytes.
That was decided in 2007.
Or perhaps you think we're starting at 0 from 2007?
No - we're using the normal epoch, but after things overflow in 2038,
it will just start back around the other side.
Clearly this may not be ideal - so at some point in the next 28 years
we may want to add a new type.