[SpringBoot JPAを使用したWebアプリケーションの開発:修正(変更の検出、マージ)]


1.セキュリティ・ホール


ID値が変更され、オーバーフローする可能性があります(セキュリティ・ホール)
サーバには、ユーザーがアイテムの権限を持っているかどうかを確認する論理があるはずです.
데이터 수정을 위해서 EntityManager 객체의 merge 메서드를 사용하지만
실무에서는 사실 거의 사용하지 않는 기능이다.

2.連結変更検出


全面的に理解しなければならない課題
[変更を検出(=dirty checking)]
JPAでは、トランザクション内の永続エンティティのデータが変更された場合、変更が検出され、データが更新されます.
내가 이해하기 쉽게 말하자면 Spring MVC에서 Transaction 안에 돌아가는 프로세스 중
DTO 클래스에 setter로 데이터 변경만 해줘도 Tsansaction이 종료되는 시점에
update 쿼리가 자동 실행되는 것 같은 느낌이라고 할 수 있을 것 같다...
Transaction commitでデータを更新せずにリフレッシュ
以下に、これらの内容に関する追加の説明を示す.
[準永続性エンティティ=永続性コンテキストによって管理されなくなったエンティティ]
データベースに格納およびロードされたデータは、データベースを1回通過するため、識別子はすでに存在します.
この場合、準ゼロスピードシンボルになります(=識別子がある場合).
JPA가 더 이상 관리하지 않음
dirty checking을 하지 않음
즉, new 로 Entity를 새로 생성하고 setter를 사용해서 데이터를 변경해도 JPA가 확인하지 않음
[準零速シンボルを修正する2つの方法]
  • を使用して検出機能
  • を変更する.
  • を使用して
  • をマージ

    2.1. 変更の検出

  • サービスは、更新されたビジネスロジックメソッド上でトランザクションを行い、Commitで
  • をリフレッシュ()
  • は、ビジネスロジックを更新して、データを識別子としてEntityにインポートし、永続的なデータ
  • を取得する.
  • 画面上のエンティティオブジェクトにデータを設定と、永続エンティティのデータが
  • 変化する.
  • のリフレッシュ()が行われ、JPAの永続構造は変更されたエンティティ(=Dirty Checking)
  • をチェックします.
  • Dirty Checkingによるデータ変更
  • [概要]
    取引でエンティティを再表示し、変更する値を選択します.
    ->トランザクションのコミット時に変更が検出され、データベースでupdate SQLが実行されます.

    トランザクションで永続性エンティティを問合せ、エンティティのデータを直接変更する必要があります。


    このようにしてこそ、トランザクションのコミット時にデータの変更が発生します.

    2.2. 併用(理論のみ知り、使用しない)


    マージ(merge)は、準永久状態にあるエンティティを永久状態に変更する際に使用される機能です.
    [理論]
    merge()を実行します.
    パラメータに渡される準ゼロ速エンティティの識別子値として、プライマリキャッシュでエンティティをクエリーします.
    ない場合は、データベースからエンティティを問合せ、プライマリ・キャッシュに格納します.
    エンティティの値をすべて変更した値に置き換え、エンティティを返します.
    ただし、パラメータに移行した準ゼロ速エンティティはゼロ速エンティティにはなりません.
    [注意]
    「変更の検出」(=Dirty Checking)を使用してデータを変更すると、エンティティの変更値のみが更新されます.
    連結を使用してデータを変更すると、エンティティのすべての属性が変更されます.
    たとえば、nameフィールドの変更のみが許可されている画面で、name以外のすべてのフィールドがNULLに設定されている場合、識別子に対応するデータの名前のみが変更され、残りのフィールドはNULLに更新されます.=地獄行きの列車
    すなわち,mergeは選択可能な概念ではない.
    [例]
    mergeを使用すると、価格は1回の価格設定後も変わりません.
    ユーザーは画面でデータを変更するときに価格値を送信しませんか?データベースの価格がnullに更新されます.
    すなわち、エンティティのフィールドが10個で、変更が4個しかない場合、残りのフィールドは更新を阻止するために余分な論理を増加させる可能性があります(=大量の管理ポイントを生成します).

    3.結論


    面倒でも、mergeではなく変更感知を使うべきです.
    mergeは一度にすべて更新され、変更検出はupdateを正しく選択するだけです.
    [その他の推奨事項]
  • エンティティは、コントローラ内で不自然に
  • を使用しないでください.
  • は、識別子をトランザクションを有するサービス層に明確に渡す