undocumented the old limitations

git-svn-id: https://svn.jboss.org/repos/hibernate/trunk/Hibernate3/doc@6795 1b8cb986-b30d-0410-93ca-fae66ebed9b2
This commit is contained in:
Gavin King 2005-05-16 06:10:26 +00:00
parent 238e6ab689
commit 2b250edff9
3 changed files with 2 additions and 25 deletions

View File

@ -198,8 +198,7 @@ kittens = cat.getKittens(); // Okay, kittens collection is a Set
<para>
<literal>fetch</literal> (optional, defaults to <literal>select</literal>) Choose
between outer-join fetching, fetching by sequential select, and fetching by sequential
subselect. Only one collection may be fetched by outer join per SQL
<literal>SELECT</literal>.
subselect.
</para>
</callout>
<callout arearefs="mappingcollection11">

View File

@ -218,26 +218,6 @@ Integer accessLevel = (Integer) permissions.get("accounts"); // Error!]]></prog
(This is Hibernate's equivalent of what some ORM solutions call a "fetch plan".)
</para>
<para>
Join fetching for collections has one limitation: you may only set one collection
role per persistent class or query to be fetched per outer join. Hibernate forbids
Cartesian products when possible, <literal>SELECT</literal>ing two collections per
outer join would create one. This would almost always be slower than two (lazy or
non-deferred) <literal>SELECT</literal>s. The restriction to a single outer-joined
collection applies to both the mapping fetching strategies and to HQL/Criteria
queries.
</para>
<para>
If you run into this limitation, you should use subselect or batch fetching to
achieve acceptable performance. This is common when retrieving a tree of
collection-valued associations.
</para>
<para>
There are no restrictions to join fetching of single-ended associations.
</para>
<para>
A completely different way to avoid problems with N+1 selects is to use the
second-level cache.

View File

@ -148,9 +148,7 @@
</para>
<para>
Note that, in the current implementation, only one collection role may be join fetched
in a query (more than one role will usually result in a cartesian product). Note also
that the <literal>fetch</literal> construct may not be used in queries called using
Note that the <literal>fetch</literal> construct may not be used in queries called using
<literal>scroll()</literal> or <literal>iterate()</literal>. Finally, note that
<literal>full join fetch</literal> and <literal>right join fetch</literal> are not
meaningful.