[1]パス式

:.オブジェクト図面を参照

select m.username
	from Member m
    	join m.team t
        join m.orders o
where t.name

m.username→ステータスフィールドm.team→単一値関連フィールドm.orders→集合値関連フィールド
フィールドは3つあります

ステータスフィールド

:値を格納するフィールドのみ
Ex. m.username

関連フィールド(関連フィールド)

:関連関係を表すフィールド
1つの値フィールドを関連付けます.@ManyToOne、OneToOne、ターゲットがエンティティ(Ex.m.team)
関連コレクション値フィールド:@OneToMany、@ManyToMany、ターゲットは集合(Ex.m.orders)

特長

ステータスフィールド(State field):パスナビゲーションの終了.ナビゲーションX
m.usernameのように.を印刷し、二度と入る場所がない

単一値の関連パス:暗黙的な内部結合が発生し、Oをナビゲートします.
気持ちよさそうですが、気をつけて使います.いいえ、
ただ、、書かないで、

集合値の関連パス:抑制された内部結合オカレンス、ナビゲーションX
-FROMセクションから別名を明示的に結合して取得する場合は、別名を使用してナビゲートできます.

明示的に署名する.

明示的な結合:joinキーを直接使用する

select m from Member m join m.team t

暗黙結合:経路式によって暗黙的にSQL結合を生成します(内部結合のみ)

select m.team from Member m

パスナビゲーションを使用するヒントチェックインの注意事項

常に内部連結

の集合は、パスナビゲーションの終了時に明示的な結合によって別名

を得る必要がある.

パスナビゲーションは主にselect、whereセクションで使用されますが、デフォルトの所有者によってSQLのfromセクション

に影響します.
最終的には実務にある.

黙示署名ではなく、できるだけ明示的な署名を使用します.

結合はSQL調整のキー

です.

黙示的な署名は、署名の発生状況を一目瞭然に理解することが困難である

.

[2]尋尋JPQL-ペッキョイン1(fetchjoin)-基本

プリフェッチ結合

SQL結合タイプ

ではありません

JPQLが提供する最適化性能機能

SQLクエリー関連エンティティまたはセットの機能

を提供します.

join fetchコマンド

を使用

プレ締結:=[LEFT[OUTER]|INNER]JOIN FETCH締結経路

エンティティペア

メンバーを問い合わせると、関連するチームも一緒に

を問い合わせる(一度のSQL)

SQLから見ると、会員だけでなくチーム(T.*)もSELECT

も含まれています

プリ結合使用コード

コレクションペア

対多関係、集合ペアリング(集合ペアリング)

コードの使用

DISTINCT

:重複データが気に入らない場合はDISTINTで削除

SQLのDISTINTコマンドで重複した結果を排除

JPQLのDISTINCTは2つの機能を提供しています.
-DISTINTをSQLに追加
-エンティティ重複除外

をアプリケーション・レベルで実行します.
📌 1対複数の署名をすると、データが誇張される可能性があります.しかし、これとは逆に多対一の関係は誇張されない.

select distinct t
from Team t join fetch t.members
where t.name = '팀A'

DISTINTをSQLに追加しましたが、データが異なるため、重複除外はSQL結果で失敗しました

DISTINCTは、他のアプリケーションから重複除外を試みます

同じ識別子を持つTeamエンティティの削除

ペッキーコネクタと普通のコネクタの違い

一般署名

一般結合の実行時に関連付けられたエンティティを同時にクエリーしない

JPQLは、結果を返すときに関連関係を考慮せずにselectセクションで指定したエンティティのみをクエリーします.

ここではチームエンティティのみがクエリーされ、メンバーエンティティはクエリーされません.

ペアリング結合を使用している場合にのみ、関連するエンティティが同時に検索されます(すぐにロードされます).
(実際には、即時ロードと考えられます.遅延ロードは指定されていますが、プリロードを使用するとプリロードよりも優先されるため、すぐにロードされます.)

プリフェッチ結合は、SQLクエリーオブジェクトのグラフィックの概念です.

プリカップリング

節は、関連するエンティティとともにクエリーを結合する

[3]プリフェッチ結合2-限界

原則として、パッチオブジェクトに別名を付けることはできません.(ex. ... as m where m.username)
ネイビーに染められるなるべく使わないでください.

2つ以上のコレクションはパッチワークできません.

集合を一緒に貼り合わせると、ページングAPI(setFirstResult、setMaxResult)は使用できません.
1対1、複数対1などの単一値関連フィールドに対して、ページング結合を行うことができます.
Hypernetはアラートログを残し、メモリにページングします(非常に危険です)

SQLによる関連エンティティの問合せ→パフォーマンスの最適化

エンティティに直接適用されるグローバル・ロード・ポリシーよりも優先
(グローバル・ロード・ポリシー:@OneToMany(fetch = FetchType.LAZY)

すべてのグローバル・ロード・ポリシーは、実際の操作では遅延ロードです.

最適化が必要な場所でプリフェッチ結合を適用

つまり。

すべてのことはパッチワークで解決できない.オブジェクトシェイプを維持するときにプリフェッチ結合を使用するのは有効です.
エンティティが持つ形状ではなく複数のテーブルを結合する必要がある場合は、ペッキー結合ではなく通常の結合を使用して、必要なデータのみを問合せ、DTOに戻るのが有効です.

[4]多形クエリ

あまり重要な内容ではありません

[5]エンティティを直接使用

JPQLでエンティティを直接使用する場合、SQLはエンティティのデフォルトキー値を使用します.

[6]Namedクエリ-静的クエリ

:あらかじめ定義して命名したJPQL

静的クエリ

のみ

宣言、XMLで

を定義可能

アプリケーションのロード時に

を初期化して再使用

アプリケーションのロード時にクエリ

を検証する

@Entity
@NamedQuery(
        name = "Member.findByUsername",
        query = "select m from Member m where m.username = :username"
)
public class Member {

[7]一括演算

在庫がn個未満のすべての商品の価格をmパーセント引き上げる場合
JPA変更検出機能を使用して実行するには、SQLが多すぎます.

在庫不足n件商品リスト照会

商品実体価格がm%

上昇

トランザクション交点変更検出動作

100個のデータが変更された場合、UPDATE SQLは100回実行されます.
バッチ演算は、1回のクエリで複数のテーブルを変更できます.

executeUpdate()は、影響を受けるエンティティ数

を返します.

UPDATE、DELETEは

をサポート

*INSERT INTO...SELECT、HyperNate(

)をサポート

注意事項

バッチ演算は、永続性コンテキストを無視し、データベースに直接クエリーを発行します.

だから
まず

の一括演算または

を実行する.

バッチ演算を実行すると、永続性コンテキストを初期化する必要があります.

JPAは難しすぎて、遅かれ早かれまた聞きますが、