#112 마이페이지 조회 API 구현

[choign3123]

📍 PR 타입 (하나 이상 선택)

• 기능 추가
• 버그 수정
• 의존성, 환경 변수, 빌드 관련 코드 업데이트
• 기타 사소한 수정

❗️ 관련 이슈 링크

• #112 마이페이지 조회 API 구현하기 #112

📌 개요

• 마이페이지 조회 API 구현

🔁 변경 사항

• 정상 응답

{
    "isSuccess": true,
    "code": "COMMON200",
    "message": "성공입니다.",
    "result": {
        "my_info": {
            "profile_name": "김테스트",
            "space_name": "테스트의 스페이스"
        },
        "insight": {
            "profile_shared_num": 2,
            "space_shared_num": 0
        }
    }
}

• 오류 응답

{
    "isSuccess": false,
    "code": "MEMBER400",
    "message": "해당하는 사용자가 존재하지 않습니다"
}

📸 스크린샷

👀 기타 더 이야기해볼 점

• sql문을 한번에 짤수있으면 그렇게 하는게 더 좋을지 고민이 됩니다.
• query문을 날리지 않고 객체조회로 끝낼 수 있는 방법이 있다면 알려주시면 감사하겠습니다!

✅ 체크 리스트

• PR 템플릿에 맞추어 작성했어요.
• 변경 내용에 대한 테스트를 진행했어요.
• 프로그램이 정상적으로 동작해요.
• PR에 적절한 라벨을 선택했어요.
• 불필요한 코드는 삭제했어요.

[yueunfive]

Paging하신 이유가 궁금합니다.

@query("select pf.profileValue " +
"from Profile p " +
"join ProfileFeature pf on p = pf.profile " +
"where pf.profileKey = 'name' and p.member = :member " +
"order by p.isDefault desc, p.createdAt asc ")
List findProfileFeature(@param("member") Member member);
...
String profileName = profileFeatureRepository.findProfileFeature(member).get(0);

이렇게 페이지네이션 처리없이 조회했을 때와 비교하여 이점이 있는 건가요?

[choign3123]

저도 paging으로 처리하고싶진 않았는데,
profile feature가 여러개 나올 수 있는 상황에서 jpql로는 sql의 limit 키워드가 안먹어서
어쩔 수 없이 paging으로 처리했습니다ㅠ 혹시 더 좋은 방법이 있다면 알려주시면 감사하겠습니다!

[yueunfive]

넵 확인했습니다. 저도 궁금해서 질문드린거라 더 좋은 방법은 모르겠네요😅

[yueunfive]

혹시 countShared"Profile"ByMember라고 작명하신 이유가 있을까요?

[choign3123]

앗! 이건 제가 잘못 작명했습니다! profile -> space로 변경하겠습니다. 꼼꼼한 확인 감사합니당

[yueunfive]

확인했습니다!