docs(articles): Magento and Symfony examples side by side, request lifecycle as a Mermaid diagram
en/articles/magento-to-symfony/data/doctrine.md
+12
โ2
66
66
67
67
## Queries: Collection โ QueryBuilder
68
68
69
+
::::columns
70
+
:::col
69
71
**Magento** ยท collection
70
72
71
73
```php
79
81
echo $question->getData('title');
80
82
}
81
83
```
82
โ
84
+
:::
85
+
:::col
83
86
**Symfony** ยท repository method
84
87
85
88
```php
105
108
}
106
109
}
107
110
```
111
+
:::
112
+
::::
108
113
109
114
In QueryBuilder and DQL you use property and class names, not column and table names: `q.isActive`, not `is_active`. Simple queries come ready-made: `find($id)`, `findOneBy(['slug' => $slug])`, `findBy([...], ['position' => 'ASC'])`.
110
115
111
116
## Saving: save() โ persist() + flush()
112
117
118
+
::::columns
119
+
:::col
113
120
**Magento**
114
121
115
122
```php
122
129
$other->setIsActive(false);
123
130
$this->questionRepository->save($other);
124
131
```
125
โ
132
+
:::
133
+
:::col
126
134
**Symfony**
127
135
128
136
```php
135
143
136
144
$this->em->flush(); // one INSERT and one UPDATE in a single transaction
137
145
```
146
+
:::
147
+
::::
138
148
139
149
:::danger subtitle="flush() is not save()"
140
150
`flush()` writes all changes to all entities the UnitOfWork knows about, not just the one you passed. If some other entity was changed somewhere up the stack and you didn't mean to save it, it gets written too. Doctrine ORM 3 removed `flush($entity)`, so old code that relied on "partial" saving has to be reviewed, not just stripped of the argument.