10-6. 演習問題
問題1:選択問題
Section titled “問題1:選択問題”1-1. DB に保存する対象クラスへ付ける注釈として最も適切なのはどれか。
- A.
@Entity - B.
@RestController - C.
@SpringBootApplication
解答と解説
正解:A. @Entity
- A が正しい。DB に保存する対象を表す。
- B は誤り。HTTP の入口である。
- C は誤り。アプリ起動入口である。
1-2. 主キーを表す注釈として最も適切なのはどれか。
- A.
@Id - B.
@PostMapping - C.
@RequestBody
解答と解説
正解:A. @Id
- A が正しい。主キーを示す。
- B と C は HTTP 処理に関する注釈であり、主キーとは無関係である。
1-3. Spring Data JPA で基本的な CRUD を扱う土台として最も適切なのはどれか。
- A.
JpaRepository - B.
StringBuilder - C.
Comparator
解答と解説
正解:A. JpaRepository
- A が正しい。基本的な CRUD をまとめて扱える。
- B と C は Java の別用途クラスであり、永続化とは無関係である。
1-4. JPA が発行した SQL を確認しやすくする設定として最も適切なのはどれか。
- A.
spring.jpa.show-sql=true - B.
server.port=0 - C.
spring.main.banner-mode=off
解答と解説
正解:A. spring.jpa.show-sql=true
- A が正しい。JPA が発行する SQL を見やすくする。
- B と C は別の設定であり、SQL 確認が目的ではない。
1-5. Entity と DTO を分ける主な理由として最も適切なのはどれか。
- A. DB 保存の都合と API 入出力の都合は責務が違うから
- B. Java では同じクラスを2回書かないと動かないから
- C. CSS を適用しやすくするため
解答と解説
正解:A. DB 保存の都合と API 入出力の都合は責務が違うから
- A が正しい。Entity は DB、DTO は API の契約を主に担う。
- B と C は誤り。技術的な本質を表していない。
問題2:穴埋め問題
Section titled “問題2:穴埋め問題”次の文章の空欄を埋めてください。
- アプリ再起動後もデータを残すことを ( ) という。
- テーブルに保存する対象クラスへ付ける注釈は
@**( )**である。 - 主キーへ自動採番を設定する注釈は
@**( )**である。 - Entity の CRUD を担う部品を ( ) という。
- JPA が内部で発行した SQL を確認するために ( ) ログを見るとよい。
解答と解説
-
永続化
データをアプリ再起動後も残すことを指す。
-
Entity
テーブルへ保存する対象クラスに付ける。
-
GeneratedValue
主キーを自動採番する設定である。
-
Repository
Entity の CRUD を担当する部品である。
-
SQL
JPA の内部動作を理解する手がかりになる。
問題3:記述問題
Section titled “問題3:記述問題”3-1. メモリ上の List<Book> ではなく DB 保存へ進む理由を説明してください。
解答と解説
3-1. DB 保存へ進む理由
メモリ上の List<Book> はサーバー再起動で消えるため、業務アプリとしては不十分である。DB へ保存すれば、再起動後もデータを保持でき、複数の処理や利用者から同じデータを参照できる。
3-2. Entity と DTO を分けると、どんな変更に強くなるか説明してください。
解答と解説
3-2. Entity と DTO を分ける利点
DB のテーブル構造や主キー戦略を変えても、API の外向けフォーマットをすぐに壊さずに済む。また逆に、API の見せ方を変えても DB モデルへの影響を限定しやすい。
3-3. なぜ SQL ログを見ると JPA の理解が深まるのか説明してください。
解答と解説
3-3. SQL ログを見る理由
JPA は便利な反面、内部で何をしているか見えにくい。SQL ログを見ることで、「本当に INSERT されたのか」「SELECT が何回走ったのか」が分かり、第5章で学んだ DB の知識と結び付けやすくなる。
問題4:ハンズオン
Section titled “問題4:ハンズオン”4-1. 保存 (POST) だけを確認する
Section titled “4-1. 保存 (POST) だけを確認する”自分のアプリで、まず登録だけを 1 ステップで確認してください。
POST /api/booksで 1 冊登録するHTTP 201が返ることを確認する- その直後にサーバーログで
insert into books ...が出るか確認する
この段階で確認できること
- API 成功と INSERT が対応している
save()が本当に DB へ到達している
4-2. 再起動後の取得 (GET) を確認する
Section titled “4-2. 再起動後の取得 (GET) を確認する”次に、再起動後も残るかだけを確認してください。
- いったんサーバーを停止し、もう一度起動する
- 再起動後に
GET /api/booksで一覧取得する - 先ほど登録した本が残っていることを確認する
- サーバーログで
select ... from books ...が出るか確認する
この段階で確認できること
- 再起動後も同じ本が取得できるなら、永続化が効いている
- GET と SELECT が対応している
4-3. 更新 (PATCH) と削除 (DELETE) を確認する
Section titled “4-3. 更新 (PATCH) と削除 (DELETE) を確認する”保存と取得が通ったら、更新と削除も 1 つずつ確認してください。
PATCH /api/books/{id}で状態を変更するHTTP 200と更新後データが返ることを確認する- サーバーログで
update books ...が出るか確認する - 次に
DELETE /api/books/{id}を実行する HTTP 204が返ることを確認する- サーバーログで
delete from books ...が出るか確認する - 最後に
GET /api/booksを実行し、削除した本が含まれないことを確認する
4-4. 故障シナリオを切り分ける
Section titled “4-4. 故障シナリオを切り分ける”上の 4-1 から 4-3 を試したあとで、次の症状が出たときに最初に確認することを書いてください。
- API は
201を返すのに DB にデータが見当たらない BookEntityを追加したのにテーブルが作られないGET /api/books/1が500になる
解答と解説
4-1 〜 4-3. 保存・取得・更新・削除の確認観点
API が成功しただけで安心せず、そのタイミングで SQL ログが出ているかを見ると、HTTP 層と DB 層が本当に連動しているか確認できる。登録で INSERT、一覧取得で SELECT、更新で UPDATE、削除で DELETE が出ていれば、JPA の流れを追えている。
4-4. 故障シナリオの切り分け
-
API は
201を返すのに DB にデータが見当たらない- SQL ログで本当に INSERT が出ているか確認する
- 接続先 DB が想定したものか確認する
-
BookEntityを追加したのにテーブルが作られない@Entityが付いているかddl-auto設定やスキャン対象パッケージを確認する
-
GET /api/books/1が500- 見つからないケースを
404へ変換しているか確認する - サーバーログで例外内容を見る
- 見つからないケースを