2021.08.17 WIL

に質問

今回のプロジェクトで最も気になる部分は、クエリーの最適化です.
JPA作成方法のみを使用しているため,ホームページ上のAPIの1つのクエリ文が25回に達する現象が発生している.

解決策

JPQLを使用してクエリー文を作成し、ロジックを最適化することを決定します.

@Query("select r from ChallengeRecord r " +
        "inner join fetch r.member " +
        "Where r.challengeRecordStatus = true and r.challenge = :challenge")
List<ChallengeRecord> findAllByChallenge(Challenge challenge);

@Query("select r from ChallengeRecord r " +
        "inner join fetch r.member " +
        "Where r.challengeRecordStatus = true and r.challenge = :challenge")
Optional<List<ChallengeRecord>> optionalFindAllByChallenge(Challenge challenge);

@Query("select c from ChallengeRecord c " +
        "inner join fetch c.challenge " +
        "inner join fetch c.member " +
        "Where c.challengeRecordStatus = true " +
        "and c.challenge.challengeId in :challengeIdList")
List<ChallengeRecord> findAllByChallengeIdList(List<Long> challengeIdList);

Inner JoinとPatchである程度最適化していますが、不満な点もあります.
どのテーブルにも様々なコラムがありますが、実際にはすべてのコラムは必要ありません.
たとえば、「メンバー」(Member)テーブル:

これらのコラムに必要なのはmember idコラムだけなら、すべてのコラムを呼ぶのは非効率だと思います.
そのため、dtoに必要な色だけを消して最適化する方法もありますが、実際にはテスト結果の照会時間が減っていることも確認できますが、問題はJPAをdtoとして使うと、JPQLを書く際に複雑すぎて効率が大幅に低下し、メンテナンスに大きな副作用があるということです.

改善点

そのため、チームメンバーと検討した結果、QueryDSLを採用することにした.

わあ...これは本当に素晴らしい新技術です
QueryDSLにハマった
JPQLの場合

このエラーはコンパイル時につかめない.
progressとexpectedのパラメータ名は間違っていますが、intelligejはそれを捕まえていません.@Queryでは「」の単純な文字列なのでIntelligeneでは区別できません.
ただし、QueryDSLを使うと、

これは実際にjavaコードで記述されており、エラーが発生した場合、intelligejは他のjavaコードのエラーをつかむようにエラーを見つけることができます.
実際、リビルド中にパラメータを単一オブジェクトからリスト(ex.memberListをmemberに変更)に変更する過程で、この点に気づかず、なぜエラーが発生し、時間を無駄にしたのか.
QueryDSLを使用すると、これらはすべてキャプチャできます.
ちょっと穴があいているようで、QueryDSLを使えば、dtoもきれいに使えます!
原始人が火を発見したときのような感じがします.これは革命です.