ObjectId plans beyond 2106

[midnight-wonderer]

Hi, we are probably dead by then, but I wonder what is the plan beyond 2106?

  As you may know, ObjectId will overflow on February 7, 2106; there are a couple of ways forward then.

• extend ObjectId by 1 byte
• do nothing, using the current specification, and let it overflow into 1970.

  These impact how we design the schema now, as we can either:

• simply store ObjectId if the plan is to extend the timestamp portion of ObjectId
• store ObjectId and time as separate fields, and never use ObjectId as time

  What do you say?

P.S. BTW, the specification is currently incorrect; the ObjectId will overflow in Feb, not in Jan.

[mdbmes]

I think we would be better off phasing out ObjectId entirely before then rather than extending it in an incremental way; the limit on counter size will become a problem too, possibly before the timestamp does.

[midnight-wonderer]

As I understand, the counter would only cause a collision if one of the following occurs.

• A single process is utilizing 2^24 ObjectIDs within one second. (Around 16M)
• The server fleet is so large that it produces multiple processes with collisions on the randomized per-process part. Effectively lower the ObjectID generations required in the first scenario.

As a mom-and-pop software shop, the counter size will be an issue in my wildest dreams; I will hire all of you guys by then.

[mdbmes]

A single process is utilizing 2^24 ObjectIDs within one second. (Around 16M)

Sure, plenty of space for typical needs; but I would want more headroom eventually to protect against software flaws that could be exposed deliberately by a collision.

[ShaneHarvey]

P.S. BTW, the specification is currently incorrect; the ObjectId will overflow in Feb, not in Jan.

We should at least confirm this and fix it in the spec.