-
-
Notifications
You must be signed in to change notification settings - Fork 505
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
doc: Review Getting Started #2650
Conversation
GromNaN
commented
Jun 21, 2024
Q | A |
---|---|
Type | doc |
BC Break | no |
Fixed issues | - |
@@ -263,12 +279,15 @@ If you want to iterate over the posts the user references it is as easy as the f | |||
|
|||
<?php | |||
|
|||
$posts = $dm->getPosts(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That was an error. $user->getPosts()
expected.
@@ -199,44 +230,29 @@ Here is how you would use your models now: | |||
Note that you do not need to explicitly call persist on the ``$post`` because the operation | |||
will cascade on to the reference automatically. | |||
|
|||
Now if you did everything correctly, you should have those two objects | |||
stored in MongoDB in correct collections and databases. You can use the | |||
`php-mongodb-admin project, hosted on github`_ to look at your |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was a PHP UI for MongoDB, but archived. Replaced with Compass.
|
||
$dm = DocumentManager::create(null, $config); | ||
$dm = DocumentManager::create(config: $config); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using named arguments here. More expressive.
You will notice that working with objects is nothing magical and you only have | ||
access to the properties and methods that you have defined yourself so the | ||
semantics are very clear. You can continue reading about the MongoDB in the | ||
:doc:`Introduction to MongoDB Object Document Mapper <../reference/introduction>`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I find this page very similar to the introduction. It shows how to instantiate the DocumentManager and create classes using mapping.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Noted. That sounds like something worth revisiting after the docs are cleared up. Ultimately, it may be something our docs team can assist with, as they did for Laravel.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Small nit in the example, but looking good other than that 👍
92d82cf
to
62d73b6
Compare
public function __construct( | ||
public string $name = '', | ||
public string $email = '', | ||
public array $posts = [], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the modeling is done the wrong direction. It's the post that should refer to the user, not the user that contains the list of posts.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree, although this may have been intentional for a "Getting Started" document so that inverse relationships could be introduced at a later point: https://www.doctrine-project.org/projects/doctrine-mongodb-odm/en/2.7/reference/bidirectional-references.html#owning-and-inverse-sides
public function __construct( | ||
public string $name = '', | ||
public string $email = '', | ||
public array $posts = [], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree, although this may have been intentional for a "Getting Started" document so that inverse relationships could be introduced at a later point: https://www.doctrine-project.org/projects/doctrine-mongodb-odm/en/2.7/reference/bidirectional-references.html#owning-and-inverse-sides
Persistent Models | ||
----------------- | ||
|
||
To make the above classes persistent, all we need to do is provide Doctrine with some mapping | ||
information so that it knows how to consume the objects and persist them to the database. | ||
To make the above classes persistent, all we need to do is provide Doctrine with |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To make the above classes persistent, all we need to do is provide Doctrine with | |
To make the above classes persistent, we need to provide Doctrine with |
MongoDB's own docs have a style guide to avoid subjective language like this. It also comes across as filler, so I have no qualms about removing it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@GromNaN: I think "all we need to do" can still be removed.
`php-mongodb-admin project, hosted on github`_ to look at your | ||
``BlogPost`` collection, where you will see only one document: | ||
After running this code, you should have those two objects stored in MongoDB in | ||
the collections "User" and "BlogPost". You can use the `MongoDB Compass`_ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the collections "User" and "BlogPost". You can use the `MongoDB Compass`_ | |
the collections "User" and "BlogPost". You can use `MongoDB Compass`_ |
Unless you were writing "the MongoDB Compass tool", you can omit "the" when referring to it as a proper noun.
stored in MongoDB in correct collections and databases. You can use the | ||
`php-mongodb-admin project, hosted on github`_ to look at your | ||
``BlogPost`` collection, where you will see only one document: | ||
After running this code, you should have those two objects stored in MongoDB in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
stored in the "User" and "BlogPost" collections.
I think we can omit "in MongoDB" to avoid repetition of "in".
Also, would the collection names end up being users
and blogposts
? I forget whether ODM uses inflection to create the namespaces for each model.
@@ -263,12 +279,15 @@ If you want to iterate over the posts the user references it is as easy as the f | |||
|
|||
<?php | |||
|
|||
$posts = $dm->getPosts(); | |||
foreach ($posts as $post) { | |||
foreach ($user->posts as $post) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is where I'd expect posts
to be a PersistentCollection. It may be too much information to mention that here (or earlier when you use a Collection interface), though, so I won't advocate for a note.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Adding a note that explains the behavior of PersistentCollection
.
reading about the MongoDB in the :doc:`Introduction to MongoDB Object Document Mapper <../reference/introduction>`. | ||
You will notice that working with objects is nothing magical and you only have | ||
access to the properties and methods that you have defined yourself so the | ||
semantics are very clear. You can continue reading about the MongoDB in the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"so the semantics are very clear" can probably be removed, as it makes the sentence run on a bit.
I'd also advocate for removing "the MongoDB" and maybe just rewriting the second sentence entirely:
You can continue reading [LINK]
You will notice that working with objects is nothing magical and you only have | ||
access to the properties and methods that you have defined yourself so the | ||
semantics are very clear. You can continue reading about the MongoDB in the | ||
:doc:`Introduction to MongoDB Object Document Mapper <../reference/introduction>`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Noted. That sounds like something worth revisiting after the docs are cleared up. Ultimately, it may be something our docs team can assist with, as they did for Laravel.
9da83a3
to
373d565
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM but one of my earlier suggestions was overlooked.
Persistent Models | ||
----------------- | ||
|
||
To make the above classes persistent, all we need to do is provide Doctrine with some mapping | ||
information so that it knows how to consume the objects and persist them to the database. | ||
To make the above classes persistent, all we need to do is provide Doctrine with |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@GromNaN: I think "all we need to do" can still be removed.
@@ -138,6 +162,13 @@ You can provide your mapping information in Annotations or XML: | |||
</document> | |||
</doctrine-mongo-mapping> | |||
|
|||
.. note:: | |||
|
|||
The `$id` property is a special property that is used to store the unique |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: technically, the property mapped with #[ODM\Id]
is special. The property name itself can be anything. If you want to address this, I'd say something like:
The
$id
property above is annotated with#[ODM\Id]
, which makes it special...
Here, I'm using "annotated" as a verb. My word choice has nothing to do with attributes vs. annotations :)
373d565
to
bb2beac
Compare
* 2.9.x: (24 commits) Fix typo in code example (#2670) Label PRs about GH actions with "CI" (#2632) Review basic mapping (#2668) Fix wording (#2667) Add native type to private properties and final classes (#2666) Review and add tests on `ResolveTargetDocumentListener` (#2660) Remove soft-delete-cookbook (#2657) doc: Remove wakeup and clone cookbook (#2663) Modernize generated code for Hydrators (#2665) Add tests for introduction (#2664) doc: Review mapping ORM and ODM cookbook (#2658) doc: Review cookbook on blending ORM and ODM (#2656) doc: Review and test validation cookbook (#2662) Update custom mapping example (#2654) doc: Review Simple Search Engine Cookbook (#2659) doc: Add cookbook about embedding referenced documents using $lookup (#2655) doc: Add type to properties (#2652) doc: Review custom collections and repository docs (#2653) doc: Review Getting Started (#2650) Move annotations-reference to attributes-reference (#2651) ...