Enable optimistic locking using an ObjectId as version field

[GromNaN]

Q	A
Type	feature
BC Break	no
Fixed issues	Related to #2789

Summary

Optimistic Locking use a version field that is incremented on each version.

• Using a int field is safe but doesn't provide any information about the last update
• Using a date field provides the last update date, but is not safe if updates occurs during the same millisecond.
• Using an a MongoDB ObjectId is perfect as it is both safe, sortable and provide the update date using ObjectId::getTimestamp()

[Copilot]

Pull Request Overview

This PR adds support for using MongoDB ObjectId as a version field for optimistic locking. This provides a unique, sortable identifier that includes timestamp information while maintaining safety from concurrent updates.

• Implements the Versionable interface for ObjectIdType with a getNextVersion() method
• Adds comprehensive test coverage for the new versioning capability
• Updates documentation to include object_id as a supported versioning type

Reviewed Changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 4 comments.

File	Description
lib/Doctrine/ODM/MongoDB/Types/ObjectIdType.php	Implements Versionable interface and adds getNextVersion() method
tests/Doctrine/ODM/MongoDB/Tests/Types/VersionableTest.php	Adds test coverage for all versionable types including new ObjectId support
docs/en/reference/transactions-and-concurrency.rst	Updates documentation to list object_id as supported versioning type

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[paulinevos]

Honestly think it would be worth explicitly mentioning somewhere the possibility of deriving the timestamp from the object ID. It's quite a good idea and will probably not occur to many users unless it's mentioned somewhere.

[jmikola]

IIRC, ODM converts ObjectId values to strings, so users won't be able to easily utilize ObjectId::getTimestamp() for that purpose. Perhaps this would warrant a separate tutorial or cookbook entry, as there's likely a bit more code involved to parse the timestamp from the string (could be done with PHP code separate from ext-mongodb).

On a separate note, ObjectIds might also encounter issues in high-concurrency environments (see: SERVER-6054). The 4-byte timestamp and 3-byte counter (see: ObjectId spec) likely provides more uniqueness than a UTCDateTime with millisecond precision, though.

[GromNaN]

Exact, the ObjectIdType convert the ObjectId into a string. You have to convert it back to ObjectId to get the timestamp.

mongodb-odm/lib/Doctrine/ODM/MongoDB/Types/ObjectIdType.php

Line 29 in 650b14d

return $value !== null ? (string) $value : null;

ObjectIds might also encounter issues in high-concurrency environments
A max of 16 millions unique ObjectId per second should be more than what a single PHP process can handle.

[jmikola]

IIRC, ODM converts ObjectId values to strings, so users won't be able to easily utilize ObjectId::getTimestamp() for that purpose. Perhaps this would warrant a separate tutorial or cookbook entry, as there's likely a bit more code involved to parse the timestamp from the string (could be done with PHP code separate from ext-mongodb).

On a separate note, ObjectIds might also encounter issues in high-concurrency environments (see: SERVER-6054). The 4-byte timestamp and 3-byte counter (see: ObjectId spec) likely provides more uniqueness than a UTCDateTime with millisecond precision, though.