Fluent nHibernate 中的 .Fetch.Select() 是什么?

发布于 2024-11-26 12:11:09 字数 730 浏览 2 评论 0原文

在使用 Fluent nHibernate 进行开发时,我注意到在关系上我可以指定一个 Fetch 属性,可能的选项有 Select()Join()Subselect()

我对这些进行了一些搜索,但得到的信息很少。我确实在 nHibernate 文档和 Fluent nHibernate 文档中找到了它们,但除了给出它们的签名之外,它几乎没有什么作用,这对我没有太大帮助。

我想知道是否有任何真正的解释来解释它们是什么以及它们的真正作用。我自己也一直很困惑。根据我自己的评估,它们似乎改变了将引用实体拉入对象图中的方式,但我还没有完全辨别它们如何改变它,以及哪一个最适合什么情况。 我确实

找到了这篇博客文章(http://www.mkyong.com/hibernate/hibernate-fetching-strategies-examples/),其中有一些细节,但我仍然对整个情况感到非常困惑。我还看到其他示例表明使用 Select() 更为优化,但其背后的原因是这样的。此外,我在 (http://community.jboss.org/wiki/AShortPrimerOnFetchingStrategies) 上发现了一篇针对原始 Java Hibernate 平台的帖子,但我认为概念是相同的。在这一点中,我的理论似乎有点被吹嘘,因为它更多地关注它们所做的延迟加载方面,但我仍然没有看到任何真正平坦的示例。

While developing with Fluent nHibernate, I notice that on relationships I can specify a Fetch property, with possible options of Select(), Join(), and Subselect().

I did some searches for these and yielded very little information. I did find them in the nHibernate documentation and the fluent nHibernate documentation, but it does little other than give their signatures, which doesn't help me too much.

I was wondering if there is any real explanation for what these are, and what they really do. I've been rather perplexed myself. From my own evaluation they seem to change the way that referenced entities are pulled into the object graph, but I've yet to entirely discern how they change it, and which one is optimal for what situation...

I did find this blog post (http://www.mkyong.com/hibernate/hibernate-fetching-strategies-examples/) that has a little bit of detail but I'm still pretty perplexed about the entire situation. I've also seen other examples that state using Select() is more optimal, but the reasoning behind it. Additionally I found a post at (http://community.jboss.org/wiki/AShortPrimerOnFetchingStrategies) that is geared towards the original Java Hibernate platform, but I presume the concept is the same. In this one, my theory seems to be blown a bit as it focuses more on the lazy loading aspect of what they do, but I've still not seen any really flat examples.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

指尖凝香 2024-12-03 12:11:09
  • 加入抓取 - NHibernate 使用 OUTER JOIN 在同一个 SELECT 中检索关联的实例或集合。

  • 选择获取 - 第二个 SELECT 用于检索关联的实体或集合。除非您通过指定lazy="false" 显式禁用延迟获取,否则第二个选择将仅在您实际访问关联时执行。

  • 子选择获取 - 第二个 SELECT 用于检索在先前查询或获取中检索到的所有实体的关联集合。除非您通过指定lazy="false" 显式禁用延迟获取,否则第二个选择将仅在您实际访问关联时执行。

查看获取策略文档 @ Nhibernate 文档

  • Join fetching - NHibernate retrieves the associated instance or collection in the same SELECT, using an OUTER JOIN.

  • Select fetching - a second SELECT is used to retrieve the associated entity or collection. Unless you explicitly disable lazy fetching by specifying lazy="false", this second select will only be executed when you actually access the association.

  • Subselect fetching - a second SELECT is used to retrieve the associated collections for all entities retrieved in a previous query or fetch. Unless you explicitly disable lazy fetching by specifying lazy="false", this second select will only be executed when you actually access the association.

Check out the fetching strategy document @ The Nhibernate Documentation

缪败 2024-12-03 12:11:09

我不太熟悉 nHibernate(我使用 Hibernate 和 Java),但基于类比,这使您能够指定您想要与给定实体急切加载的关联/集合属性。当您无法完全控制 (n)Hibernate 会话时(即,如果 Java 中的 Spring 等其他框架正在处理会话/事务),这非常有用。
所以你的假设基本上是正确的。
Select、Join、Subselect是获取相关属性的方法,并决定在数据库中执行什么样的查询。哪一种是最佳的,实际上取决于您的情况。

希望这会有所帮助,
干杯。

I'm not really familiar with nHibernate (I work with Hibernate and Java), but based on analogy, this enables you to specify association/collection property which you want to load eagerly, with the given entity. This is useful when you don't have full control over (n)Hibernate sessions (i.e if some other framework like Spring in Java is taking care of sessions/transactions).
So your assumption is basically correct.
Select, Join, and Subselect are the ways to obtain the related property, and determine what kind of query will be performed in database. Which one is optimal, really depends on the situation you have.

Hope this helps a little,
Cheers.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文