将 Doctrine 的 EntityManager 保存在会话变量中
我正在开发一个网络应用程序，我将使用教义框架来管理， 并发请求和事务查询（例如插入或更新头记录和行记录）。
对于网络必需品，我认为将操作分为不同的步骤： 第一步：我有一个页面，允许用户插入 HeadTable 记录，然后将信息发送到服务器，创建一个实体并将其存储在具有持久功能的 EntityManager 中。
第二步：用户将编辑并插入所有RowsTable记录。当这一切完成后，像以前一样，我将所有数据发送到服务器，创建实体并将它们关联到 HeadTable 记录。
最后一步：当用户确认他已完成的所有操作时，我触发 EntityManager 的刷新操作，并在单个原子事务中将所有内容提交到数据库。 为了将所有这些步骤放在一起，我将 EntityManager 放入会话变量中，并在刷新操作后将其删除。
一切似乎都很好，但我想知道这是否是解决问题的正确方法或者是否有更好的方法。
I'm developing a web-application and I'm going to use docrine framework to manage,
concurrent requests and transactional queries (like inserting or updating head and rows records).
For web necessities I thought to split operations in different steps:
First step: I have a page that allows the user for inserting a HeadTable record and after that I send the information to the server, create a Entity and store it in a EntityManager with a persist function.
Second step: The user will edit and insert all the RowsTable records. When it's all done, like before, I send all the data to the server, create Entities and Associate them to the HeadTable record.
The final step: When the user confirm all he has done, I trigger the flush operation of the EntityManager and commit all to DataBase in a single atomic transaction.
To keep all this steps toghether I put the EntityManager in a session variable and I remove it after the flush operation.
All seems to be fine but i would like to know if it's the correct way to resolve the problem or if there's a better way.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
听起来是一个合理的尝试。
但是，我可能会避免跨请求存储实体管理器。它有一个数据库连接需要担心，因此可能会中断。
然而，您可以做的只是将实体存储在会话中。将它们从实体管理器中分离出来，然后在下一个请求时将它们合并回来。
Sounds like a reasonable thing to try.
I'd probably avoid storing the entitymanager across requests, however. It's got a database connection to worry about, and will therefore probably break.
What you can do, however, is just store your entities in session. detach() them from their entitymanager, and then merge() them back on the next request.