sqlalchemy恒等映射问题
身份映射和工作单元模式是 sqlalchemy 比 django.db 更具吸引力的部分原因。但是，我不确定身份映射如何工作，或者当应用程序配置为 wsgi 并且直接通过 api 调用而不是共享服务访问 orm 时它是否工作。我想象 apache 会为每个请求创建一个带有自己的 python 实例的新线程。因此，每个实例都有自己的 sqlalchemy 类实例，并且无法使用标识映射。这是正确的吗？
The identity map and unit of work patterns are part of the reasons sqlalchemy is much more attractive than django.db. However, I am not sure how the identity map would work, or if it works when an application is configured as wsgi and the orm is accessed directly through api calls, instead of a shared service. I would imagine that apache would create a new thread with its own python instance for each request. Each instance would therefore have their own instance of the sqlalchemy classes and not be able to make use of the identity map. Is this correct?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我认为您误解了身份映射模式。
来自：http://martinfowler.com/eaaCatalog/identityMap.html
单个业务交易的记录保存在身份映射中。这意味着无论您的 Web 服务器如何配置，您保存它们的时间可能不会超过请求（或将它们存储在会话中）。
通常，不会有很多用户参与单个业务交易。无论如何，您可能不希望您的用户共享对象，因为他们最终可能会做矛盾的事情。
I think you misunderstood the identity map pattern.
From : http://martinfowler.com/eaaCatalog/identityMap.html
Records are kept in the identity map for a single business transaction. This means that no matter how your web server is configured, you probably will not hold them for longer than a request (or store them in the session).
Normally, you will not have many users taking part in a single business transation. Anyway, you probably don't want your users to share objects, as they might end up doing things that are contradictory.
所以这一切都取决于您如何设置 sqlalchemy 连接。通常，您要做的就是管理每个 wsgi 请求以拥有自己的线程本地会话。本次会议将了解所有发生的事情、添加/更改的项目等。然而，每个线程都不知道其他线程。通过这种方式，模型和映射的加载/预配置在启动时被共享，但是每个请求可以独立于其他请求运行。
So this all depends on how you setup your sqlalchemy connection. Normally what you do is to manage each wsgi request to have it's own threadlocal session. This session will know about all of the goings-on of it, items added/changed/etc. However, each thread is not aware of the others. In this way the loading/preconfiguring of the models and mappings is shared during startup time, however each request can operate independent of the others.