Denormalization data in MongoDb Doctrine Symfony 2
I am following this document
and
http://symfony.com/doc/current/bundles/DoctrineMongoDBBundle/index.html
When I save my document I have two collections
like this:
{
"_id" : ObjectId("5458e370d16fb63f250041a7"),
"name" : "A Foo Bar",
"price" : 19.99,
"posts" : [
{
"$ref" : "Embedd",
"$id" : ObjectId("5458e370d16fb63f250041a8"),
"$db" : "test_database"
}
]
}
I would like to have
{
"_id" : ObjectId("5458e370d16fb63f250041a7"),
"name" : "A Foo Bar",
"price" : 19.99,
"posts" : [
{
"mycomment" :"dsdsds"
" date" : date
}
]
}
I want to denormalize my data. How can i do this?
Can I use methods like $ push, $ addToSet, etc. mongoDb?
thank
source to share
Doctrine ODM supports both links and inline documents .
In the first example, you are using links. The main document (let's call it Product) links to many Post documents. These Post docs live in their own collection (it's called for some reason Embedd
- I'd suggest renaming if you keep this schema). By default, ODM uses the DBRef convention for links, so each link is itself a small inline document with $ref
, $id
and fields $db
.
Denormalization can be achieved with inline docs (matching @EmbedMany
in your case). If you are pasting a Post document, the Post class should appear as @EmbeddedDocument
. This tells ODM that it is not a first-class document (belonging to its own collection), so it won't have to worry about tracking it with _id
and the like (in fact, inline documents don't even need IDs, unless you want to match it).
My rule of thumb for deciding whether to embed or links tended to ask myself, "Do I need this document outside of the context of the parent document?" If the Mail does not have identification information outside the product record, I will be able to easily embed it; however, if later I find that my application also wants to show users a list of all its Posts, or that I need to request posts (for example, a feed of all recent Posts, regardless of the product), then I might want to link documents in the post collection (or just duplicate embedded entries as needed).
Alternatively, you can decide that Posts should exist both in their own collection and be embedded in the Product. In this case, you can create an AbstractPost class as @MappedSuperclass
and define common fields there. Then extend this with Post and EmbeddedPost subclasses (mapped accordingly). You will be responsible for generating some code to create an EmbeddedPost from a Post document that is suitable for embedding into an array Product.posts
. In addition, you will need to handle data synchronization between uploader and inline posts (for example, if someone is editing a Post comment, you can update all relevant inline versions as well).
Regarding references: ODM also supports a parameter simple
for reference mappings, in which case it will simply store the referenced document _id
instead of the larger DBRef object. In most cases, having DBRef storing the collection and database name for each referenced document is rather redundant; however, DBRef is really useful if you are using single collection inheritance , because ODM uses this object to store additional discriminator information (i.e. the class of the object being referenced).
source to share