Conversation
There was a problem hiding this comment.
- created_chat_tab = service.store_chat_tab(chatName),
updated_chat_tab = service.updated_chat_tab(tabId, chatName) 이 두 부분 받아올 때 모델로 안받아오나요??
확인했더니 객체로 받아오는 것 같은데 reponse 객체를 만들던가 아니면 해당 객체를 그대로 보내던가 하는 방법이 가독성이 좋을 거 같습니다! - tabId는 ChatTabUpdate 여기에서 안받아오나요??
There was a problem hiding this comment.
- 아 해당 부분 response 객체로 반환하려면 서비스쪽에서 보내준 ChatInDB 객체를 딕셔너리로 변환해서 넘겨줘야하는데 그게 나을까요?
만약 변경된다면 아래와 같이 변경됩니다. response객체는 이미 만들어져있긴 합니다.
# 1. 서비스에서 받은 ChatTabInDB Pydantic 객체를 딕셔너리로 변환
created_data_dict = created_chat_tab.model_dump()
# 2. 딕셔너리를 사용하여 ChatTabResponse 객체를 생성
response_data = ChatTabResponse.model_validate(created_data_dict)
- 질문의 의도를 파악하지 못했습니다. 프론트쪽에서 chat_tab_name으로 받는게 아니라 tabID를 파라미터로 받아서 해당 값에 대한 chat_tab을 수정하는건데 ChatTabUpdate 객체에서 받아오라는 말씀이신건지?
There was a problem hiding this comment.
- repository에서 반환 자체를 response객체로 받으면 안되나요??
- chatTabUpdate 이 부문에 tabId를 받아서 넘어오는지 안받아서 온다면 지금처럼 구성하신 이유가 뭔지 궁금합니다!
tab_id가 key 값이라 객체에서 받아올 수도 있을 거 같아서 어떤식으로 받는지에 대한 궁금증이었습니다!
There was a problem hiding this comment.
- 이 부분은 아마 제가 api key 모델 구성할 때 사용한 방식을 차용하신 것 같습니다.
아시겠지만Repository에서 데이터를 반환하는 객체와,Service에서 데이터를 반환하는 객체를 분리하면 추후Presentation에서 반환할 데이터에 변동사항이 생길 때 수정사항이 줄어드는 이점이 있습니다.
대신 관리해야되는 클래스가 늘어나기에 생기는 불편도 있구요.
API 명세가 확정된 느낌보다는 자주 변동이 생길 수 있을 것 같았기에 저는 이 방식을 채택해서db_model과response_model의 필드 목록이 다르지만 현재 chat_tab에서는 승우님이 말씀하신 것처럼 response 객체로 받아도 무방한 것 같습니다.
There was a problem hiding this comment.
이 부분은 하나의 메서드만 존재하다면 utils 내부로 들어가는 게 좋아보입니다.
There was a problem hiding this comment.
모델 검증 로직만 있어서 해당 파일을 삭제하고, validate_chat_tab_name 메서드를 ChatTabBase로 옮기는게 좋을 것 같습니다.
There was a problem hiding this comment.
uuid 가져오는 부분은 이넘 생성했으니 추후 확인 후 수정해주시면 됩니다.
There was a problem hiding this comment.
그럼 DB 쪽 머지 후 진행하는게 나을까요 ? 아니면 바로 추가할까요?
There was a problem hiding this comment.
- 이 부분은 아마 제가 api key 모델 구성할 때 사용한 방식을 차용하신 것 같습니다.
아시겠지만Repository에서 데이터를 반환하는 객체와,Service에서 데이터를 반환하는 객체를 분리하면 추후Presentation에서 반환할 데이터에 변동사항이 생길 때 수정사항이 줄어드는 이점이 있습니다.
대신 관리해야되는 클래스가 늘어나기에 생기는 불편도 있구요.
API 명세가 확정된 느낌보다는 자주 변동이 생길 수 있을 것 같았기에 저는 이 방식을 채택해서db_model과response_model의 필드 목록이 다르지만 현재 chat_tab에서는 승우님이 말씀하신 것처럼 response 객체로 받아도 무방한 것 같습니다.
There was a problem hiding this comment.
모델 검증 로직만 있어서 해당 파일을 삭제하고, validate_chat_tab_name 메서드를 ChatTabBase로 옮기는게 좋을 것 같습니다.
| class ChatTabCreate(ChatTabBase): | ||
| """새로운 Chat Tab 생성을 위한 스키마""" | ||
|
|
||
| def validate_with_name(self) -> None: |
There was a problem hiding this comment.
이 메서드는 존재만 하고 실제 호출되지 않는 것 같습니다.
| """채팅 탭 이름 수정을 위한 스키마""" | ||
| name: str | None = Field(None, description="수정할 채팅 탭 이름") | ||
|
|
||
| def validate_with_name(self) -> None: |
There was a problem hiding this comment.
이 메서드도 존재만 하고 실제로 호출되지 않는 것 같습니다.
| chatName.validate_with_name() | ||
| validate_chat_tab_name(chatName.name) |
There was a problem hiding this comment.
검증 로직은 모델에 일임하는게 좋을 것 같습니다.
위에서 언급한대로 base_model로 검증 메서드를 옮긴 후 chatName의 메서드를 통해 직접 검증하도록 설정하는게 좋을 것 같습니다.
validation_utils.py로 따로 분리한 이유는 불필요한 코드 중복을 피하기 위함인 것 같지만 base_model의 메서드로 만들어서 이를 상속받는게 더 좋은 해결책일 것 같습니다.
기능상 문제는 없기에 나중에 리팩토링 해도 되고 편하신대로 해주세요.
apaals2
force-pushed
the
feature/update-ai-chat-tab
branch
from
6a3b7e3 to
a6950f8
Compare
3 participants
JIRA Task 🔖