Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

translated "6.3.4. Eager and Lazy Fetching" #38

Merged
merged 1 commit into from

3 participants

@yamkazu
Collaborator

No description provided.

@tyama tyama merged commit 00ee4d4 into jggug:master
@yamkazu yamkazu deleted the unknown repository branch
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Commits on Mar 29, 2013
  1. @sumio
This page is out of date. Refresh to see the latest.
Showing with 27 additions and 12 deletions.
  1. +27 −12 guide/GORM/persistenceBasics/fetching.gdoc
View
39 guide/GORM/persistenceBasics/fetching.gdoc
@@ -1,4 +1,5 @@
-Associations in GORM are by default lazy. This is best explained by example:
+{hidden}Associations in GORM are by default lazy. This is best explained by example:{hidden}
+GORMでは、関連のあるドメインクラスのインスタンスは、デフォルトでlazyに取得するように振る舞います。以下に例を示します:
{code}
class Airport {
@@ -22,7 +23,8 @@ class Location {
}
{code}
-Given the above domain classes and the following code:
+{hidden}Given the above domain classes and the following code:{hidden}
+上記のようなドメインクラスが定義されているとして、以下のコードを考えます:
{code}
def airport = Airport.findByName("Gatwick")
@@ -31,11 +33,16 @@ for (flight in airport.flights) {
}
{code}
-GORM will execute a single SQL query to fetch the @Airport@ instance, another to get its flights, and then 1 extra query for _each iteration_ over the @flights@ association to get the current flight's destination. In other words you get N+1 queries (if you exclude the original one to get the airport).
+{hidden}GORM will execute a single SQL query to fetch the @Airport@ instance, another to get its flights, and then 1 extra query for _each iteration_ over the @flights@ association to get the current flight's destination. In other words you get N+1 queries (if you exclude the original one to get the airport).{hidden}
+このコードを実行すると、GORMは、まず、@Airport@インスタンスを取得するためのSQLを発行します。
+次に、@airport.flights@にアクセスしようとして、その@Airport@が所有している@Flight@インスタンスの集合を取得するためのSQLを発行します。
+それから、 @airport.flights@内に格納されている各@Flight@インスタンスについて、そのフライトの@destination@を取得するために、 _それぞれ_ 1回のSQLを発行します。以上をまとめると、上記コード実行のために N+1 回のクエリーが発行されることになります(初回の@Airport@インスタンスを取得するためのクエリーを除く)。
-h3. Configuring Eager Fetching
+{hidden}h3. Configuring Eager Fetching{hidden}
+h3. Eagerフェッチングのための設定
-An alternative approach that avoids the N+1 queries is to use eager fetching, which can be specified as follows:
+{hidden}An alternative approach that avoids the N+1 queries is to use eager fetching, which can be specified as follows:{hidden}
+N+1 回のクエリーが発行されてしまうことを回避するためのアプローチの1つに、eagerフェッチングがあります。eagerフェッチングを使うには、以下のように指定します:
{code}
class Airport {
@@ -47,15 +54,21 @@ class Airport {
}
{code}
-In this case the @flights@ association will be loaded at the same time as its @Airport@ instance, although a second query will be executed to fetch the collection. You can also use @fetch: 'join'@ instead of @lazy: false@ , in which case GORM will only execute a single query to get the airports and their flights. This works well for single-ended associations, but you need to be careful with one-to-manys. Queries will work as you'd expect right up to the moment you add a limit to the number of results you want. At that point, you will likely end up with fewer results than you were expecting. The reason for this is quite technical but ultimately the problem arises from GORM using a left outer join.
+{hidden}In this case the @flights@ association will be loaded at the same time as its @Airport@ instance, although a second query will be executed to fetch the collection. You can also use @fetch: 'join'@ instead of @lazy: false@ , in which case GORM will only execute a single query to get the airports and their flights. This works well for single-ended associations, but you need to be careful with one-to-manys. Queries will work as you'd expect right up to the moment you add a limit to the number of results you want. At that point, you will likely end up with fewer results than you were expecting. The reason for this is quite technical but ultimately the problem arises from GORM using a left outer join.{hidden}
+このようにすることで、@Airport@インスタンスを取得する時に、同時に、関連している@flights@も取得するようになりますが、それぞれ別のクエリーが発行される点は変わりません。@lazy: false@の代わりに@fetch: 'join'@を使うと、1回のクエリーで、@Airport@インスタンスと、それに関連する@flights@を取得するようになります。ところが、@fetch: 'join'@を使う方法は、単一端関連ではうまく動作するのですが、この例のような1対多の関連に適用する場合には注意が必要です。具体的には、取得するレコード数に上限(@limit@)を指定しなければ、クエリーは問題なく動作するものの、上限を指定すると、本来返されるべき数よりも少ないレコードしか取得できないという事象が発生してしまいます。このようなことが発生する理由は技術的なもので、GORMが、この機能を実現するためにleft outer joinを使っていることに起因します。
-So, the recommendation is currently to use @fetch: 'join'@ for single-ended associations and @lazy: false@ for one-to-manys.
+{hidden}So, the recommendation is currently to use @fetch: 'join'@ for single-ended associations and @lazy: false@ for one-to-manys.{hidden}
+以上の理由により、現時点では、単一端関連では@fetch: 'join'@を、1対多関連では@lazy: false@を使うことを推奨します。
-Be careful how and where you use eager loading because you could load your entire database into memory with too many eager associations. You can find more information on the mapping options in the [section on the ORM DSL|guide:fetchingDSL].
+{hidden}Be careful how and where you use eager loading because you could load your entire database into memory with too many eager associations. You can find more information on the mapping options in the [section on the ORM DSL|guide:fetchingDSL].{hidden}
+あまりに多くの関連をeagerフェッチングとしてしまうと、データベース全体がメモリにロードされてしまう可能性があるため、eagerフェッチングを採用する場合は、使うべき場所と方法について十分に注意するようにしてください。@mapping@に指定できるオプションについての詳しい情報は[ORM DSLの章|guide:fetchingDSL]に記載されています。
-h3. Using Batch Fetching
+{hidden}h3. Using Batch Fetching{hidden}
+h3. 一括フェッチングの利用
-Although eager fetching is appropriate for some cases, it is not always desirable. If you made everything eager you could quite possibly load your entire database into memory resulting in performance and memory problems. An alternative to eager fetching is to use batch fetching. You can configure Hibernate to lazily fetch results in "batches". For example:
+{hidden}Although eager fetching is appropriate for some cases, it is not always desirable. If you made everything eager you could quite possibly load your entire database into memory resulting in performance and memory problems. An alternative to eager fetching is to use batch fetching. You can configure Hibernate to lazily fetch results in "batches". For example:{hidden}
+eagerフェッチングが適切なケースはもちろん有りますが、常に最適なわけではありません。
+たとえば、全てをeagerフェッチングにしてしまうと、データベース全体がメモリにロードされ、性能問題やメモリ不足の問題が発生するでしょう。そこで、eagerフェッチングに代わるもう1つの選択肢として一括フェッチングが用意されています。一括フェッチングでは、あるまとまった複数のレコードを1単位として、lazyフェッチングするように設定することができます。以下に例を示します:
{code:java}
class Airport {
@@ -67,7 +80,8 @@ class Airport {
}
{code}
-In this case, due to the @batchSize@ argument, when you iterate over the @flights@ association, Hibernate will fetch results in batches of 10. For example if you had an @Airport@ that had 30 flights, if you didn't configure batch fetching you would get 1 query to fetch the @Airport@ and then @30@ queries to fetch each flight. With batch fetching you get 1 query to fetch the @Airport@ and 3 queries to fetch each @Flight@ in batches of 10. In other words, batch fetching is an optimization of the lazy fetching strategy. Batch fetching can also be configured at the class level as follows:
+{hidden}In this case, due to the @batchSize@ argument, when you iterate over the @flights@ association, Hibernate will fetch results in batches of 10. For example if you had an @Airport@ that had 30 flights, if you didn't configure batch fetching you would get 1 query to fetch the @Airport@ and then @30@ queries to fetch each flight. With batch fetching you get 1 query to fetch the @Airport@ and 3 queries to fetch each @Flight@ in batches of 10. In other words, batch fetching is an optimization of the lazy fetching strategy. Batch fetching can also be configured at the class level as follows:{hidden}
+このコードでは@batchSize@引数が指定されています。この指定によって、@flights@が保持している各@Flight@インスタンスにアクセスするときに、10個単位で、一括して結果を取得するようになります。例えば、ある@Airport@インスタンスが30個の@Flight@インスタンスを保持しているとします。一括フェッチングが指定されていなければ、1つの@Flight@インスタンスにつき1回のクエリーを発行するので、全@Flight@インスタンスにアクセスするには、合計30個のクエリーが必要になります。一方、一括フェッチングが上記のように指定されていれば、10個の@Flight@インスタンスを1回のクエリーで取得するようになるので、必要なクエリーの数は3回になります。すなわち、一括フェッチングは、lazyフェッチングの最適化の1手法と言うことができます。なお、一括フェッチングは、以下のように、クラスのレベルで指定することも可能です:
{code:java}
class Flight {
@@ -78,4 +92,5 @@ class Flight {
}
{code}
-Check out [part 3|http://blog.springsource.com/2010/07/28/gorm-gotchas-part-3/] of the GORM Gotchas series for more in-depth coverage of this tricky topic.
+{hidden}Check out [part 3|http://blog.springsource.com/2010/07/28/gorm-gotchas-part-3/] of the GORM Gotchas series for more in-depth coverage of this tricky topic.{hidden}
+この部分について、より深く、網羅的な知識が必要な場合には、[GORM Gotchas (Part 3)|http://blog.springsource.com/2010/07/28/gorm-gotchas-part-3/]の記事を参照してください。
Something went wrong with that request. Please try again.