[JPA] JPA Study 3

4336 ワード
JPA テキストリンク

  • @Validエラーが発生した場合、結果値をどのように表示するか→後で適用

  • エンティティの変更後にAPI仕様が変更されると問題になります.(@NotEmptyをnameに割り当て、name→usernameに変更するとapi specが変わります.)→解決:DTOを作成します.
  • もう一つの問題は、DTOを作成すると、どの値を超えているかを正確に知ることができることです.DTOなしでメンバーオブジェクト自体をスキップした場合、どの値がオーバーフローするか分かりません.
  • 実務では、エンティティは決して公開されません.

  • commandとqueryを別々に設計し、メンテナンス性を向上
  • ex)会員名が更新されると、会員対象に戻ることができますが、この場合会員対象は準永久状態になります.したがって、command+queryは組み合わせられるので、分離することができる.

  • 主にクエリーでパフォーマンスの問題が発生します.

  • ページ分けの際、ユーザーが注文した商品を見たとき、注文した商品が2つであれば、2つのクエリーがありますが、これはどうやって解決しますか?

  • Javaが変数関数(String.s)の場合、関数(s 1、s 2、s 3)はこのように複数のString値を割り当てることができます(私が知りたいのは)

  • オーダークエリv 2の問題は、N+1でクエリされることである.
  • 注文が2つあり、注文の会員(N)、出荷(住所、N)すると、1回の照会で失敗し、会員、出荷は注文数によって照会されます
    つまり、上記のケースでは5回のクエリー(注文が何万回あったら、、?)

  • (復習)fetch join,N+1次クエリはjoin fetchを介してDBから1つの部屋クエリにインポートされると,これらは永続性コンテキストに保存され,クエリは失敗せず,ここからインポートすればよい.
  • N+1はfetch joinによって解決される.90%の問題はこれで解決した.

  • 受注照会v 4
    • return em.createQuery(
                "select new jpabook.jpashop.repository.OrderSimpleQueryDto(o.id, m.name, o.orderDate, o.status, d.address) " +
                        "from Order o" +
                        " join o.member m" +
                        " join o.delivery d", OrderSimpleQueryDto.class)
                        .getResultList();

    }
  • DTOおよびselect o from Order o~は、oおよびOrder SimpleQuery Dtoをマッピングしない.
    Orderオブジェクトを入れないで、o.id,m.nameと名前を付けます.このようにoを入れると、識別子として認識されないからです.
    -newコマンドを使用してJPQLの結果を直ちにDTOに変換
    -注文照会v 4コードを見るだけでは再利用性がない.最悪のメンテナンス(v 3よりもパフォーマンスが優れているのみ、selectインポート時に最適化が少ない)
  • コレクションクエリーv 1でforEach構文はgetterのみを使用します.変数に値を割り当てるにはどうすればいいですか?好奇心がわく
  • エージェントオブジェクトの概念を遅延ロードすることによってエージェントオブジェクト(エンティティエージェントオブジェクト、e.g.Team)をロードし、getName()とともにメソッドを使用するときにデータベースから実際のオブジェクトをインポートします.
  • エンティティは絶対に露出できませんが、Addressなどの価値オブジェクトは可能です.
  • JSONを返す場合は、クエリで得られた値を返さずにグループ化して返します!
  • fetch joinはorderとorderItemを接続しており、orderは2個、orderItemsは4個であるため、注文は4個(注文は2個しか現れない)→データ詐欺→この場合は「distinct」を使用し、色の他の値が重複しないにもかかわらず、オブジェクトのIDが同じであれば削除を繰り返す.データベース行を減らします.短所:ページ分けができない
  • hibernate.default_batch_fetch_size == @Batchsize
  • このオプションを使用すると、INクエリクエリ
    • を使用して、コレクションまたはプロキシオブジェクトごとに一度に設定するサイズが使用されます.
    クエリー
  • エンティティ
    エンティティを問い合せて返す:V 1
    エンティティクエリ後のDTO:V 2への変換
    プリフェッチ結合を使用したクエリー数の最適化:V 3
    コレクションのページングと突破限界:V 3.1
  • の集合は、併合時にページを分割することはできない
    • .
  • ToOne関係はバッチ結合であり、クエリ数最適化セットはバッチ結合ではなく遅延ロードを保持します.hibernate.default batch fetch size,@BastchSize
    • に最適化
    ダイレクトクエリ
  • DTO
    直接JPAからDTO:V 4を問い合わせる
    コレクションクエリーの最適化-複数の関係コレクションのペアINセグメントを使用してメモリ内で事前にクエリーを行い、最適化:V 5
    フラットデータの最適化:JOIN結果をアプリケーションに直接変換するために必要な外観:V 6
    • →個人V 3.1は私に適しているように見えますが、エンティティクエリーで問題が発生した場合、DTOクエリーのコードの読み取りが悪く、データが多ければ多いほどページング処理が重要になり、パフォーマンスが重要になるので、JDbcTemplateを使用するので、それを使用するとより良いです.
    体得:開発時に性能最適化vsコードの複雑さを考慮すべきである.

  • 以降、ユーザが多い場合はRedisキャッシュが使用されますが、この場合はエンティティをキャッシュするのではなく、DTOをキャッシュする必要があります.

  • OSIVポリシーは、トランザクションの開始と同様に、最初のデータベース接続からAPI応答の終了まで、永続性コンテキストとのデータベース接続を常に維持します→したがって、ロードを遅延させることができます.
  • Butは長い間、データベース接続リソースを噛み締めていました.これにより、障害が発生する可能性があります.
  • リアルタイム通信は重要なサービスではあまりよくありません.

  • OSIVをオフにしますか?
  • すべての遅延ロードは、トランザクション内で処理する必要があります.
  • ビジネスロジックをサービスに移行し、@Transactional処理を行う必要があります.
    • gitignore
    JSONデータを使用する方法