[SERVER-10481] Shard key inserted ahead of timestamp field, preventing auto-generation Created: 09/Aug/13  Updated: 10/Dec/14  Resolved: 14/Aug/13

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: David Wagner Assignee: Stennie Steneker (Inactive)
Resolution: Duplicate Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates SERVER-1650 Server Side Timestamps Closed
Participants:

 Description   

If a collection is sharded, and has a non-timestamp _id field, then there is no way to get a server-side timestamp to be generated in a document in that collection. This is because the server puts the _id and shard key into the first two fields of the document, and the server does not scan beyond the second field looking for uninitialized timestamps. Also see CSHARP-672, which is a different manifestation of this problem.



 Comments   
Comment by David Wagner [ 14/Aug/13 ]

This is nuts. The code is already there to do server side creation timestamps. SERVER-1650 is asking for server side update timestamps. That's a much bigger feature, it seems to me that by lumping this in with a 3-year-old, bigger feature request, it pretty much guarantees it will never be done when in fact this is a minor change to the code. I've already modified my local copy of the mongod code to handle this so I know it can be done.

Comment by Stennie Steneker (Inactive) [ 14/Aug/13 ]

Hi David,

There is currently no official support for server-side timestamps. The approach you are using is a side effect of the historical internal timestamp implementation for replication, and as such may not work as expected for sharded environments or through application drivers.

I'm going to close this issue as a duplicate of SERVER-1650, which is the feature suggestion for server side timestamps. Please upvote/watch that issue for updates.

Regards,
Stephen

Generated at Thu Feb 08 03:23:17 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.