docs(articles): Magento and Symfony examples side by side, request lifecycle as a Mermaid diagram
uk/articles/magento-to-symfony/data/doctrine.md
+12
−2
66
66
67
67
## Запити: Collection → QueryBuilder
68
68
69
+
::::columns
70
+
:::col
69
71
**Magento** · колекція
70
72
71
73
```php
79
81
echo $question->getData('title');
80
82
}
81
83
```
82
−
84
+
:::
85
+
:::col
83
86
**Symfony** · метод репозиторію
84
87
85
88
```php
105
108
}
106
109
}
107
110
```
111
+
:::
112
+
::::
108
113
109
114
У QueryBuilder і DQL пишуть імена властивостей і класів, а не колонок і таблиць: `q.isActive`, а не `is_active`. Прості запити є готові: `find($id)`, `findOneBy(['slug' => $slug])`, `findBy([...], ['position' => 'ASC'])`.
110
115
111
116
## Збереження: 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(); // один INSERT і один UPDATE в одній транзакції
137
145
```
146
+
:::
147
+
::::
138
148
139
149
:::danger subtitle="flush() — не save()"
140
150
`flush()` записує всі зміни всіх сутностей, які знає UnitOfWork, а не одну передану. Якщо десь вище по стеку змінили іншу сутність і не хотіли її зберігати, вона теж запишеться. У Doctrine ORM 3 виклик `flush($entity)` прибрали, тож старий код, що покладався на «часткове» збереження, треба переглядати, а не просто видаляти аргумент.