Unknown Summary
In the Doctrine ODM, users can map documents as embedded documents, storing all data in the parent document, or as references where data is stored in a separate collection. This leaves out one big advantage of MongoDB schema design, where data is duplicated strategically to improve read performance.
Motivation
Who is the affected end user?
Customers with complex data model that would benefit from duplicating data.
How does this affect the end user?
These hybrid references can only be mapped by using a combination of embedded documents and references, requiring advanced knowledge of inner ODM workings to support these use cases. On top, this also requires a more complex class structure to make the reference transparent and hide the fact that it in fact consists of an embedded document that in turn references a separate document.
How likely is it that this problem or use case will occur?
This is very frequent, with common use cases being:
- storing the last five reviews on a product in an e-commerce application, with all reviews being stored in a separate collection for performance reasons
- duplicating author data in a blog post to avoid using $lookup when displaying said blog post
If the problem does occur, what are the consequences and how severe are they?
There are two consequences of this. The mapping complexity was already mentioned, but users are also left alone in updating the duplicated data. Since the Doctrine ODM does not support using array filters for updates, it often forces users to leave the comfort of the ODM and step down to the driver level to properly update duplicated data when necessary. This could be avoided if the Doctrine ODM knew about such hybrid references, what data is duplicated, and can trigger updates of duplicated data when the canonical data itself is updated.
Cast of Characters
Engineering Lead: andreas.braun@mongodb.com
Document Author:
Product Owner: rishabh.bisht@mongodb.com
Program Manager:
Stakeholders: