개요
중간 프로젝트를 하면서 고민했던 부분들입니다. 주된 고민은
User의 상속을 다시 살려서, 시도해보려고 했을 때 장점과 단점
카테고리(판매자가 파는 상품의 카테고리, 판매자가 가지고 있어야함) 구현에 OneToMany로 카테고리 테이블을 참조해도 될 것인가?(List로 뽑기 위해)
- 카테고리 만들기 ( 효근님)
Seller가 가지고 있는 것임. String 으로 합시다…판매자 정보에 들어가야 합니다 필드에 있습니다.
-
이게…String으로 넣으면 리스트로 해줄 수 있는 알고리즘 적 로직이 필요합니다
-
split < 로 문자열 어떻게든 짤라서 for문 써서 그냥 넣고 짜르고 이쁘게 싹
- 판매자가 처음에 판매등록 할 때 “고양이, 고양이모래, 등등” 이케 < 이것만 보여줘도…?
- 테이블 그냥 만듭시다. 만들어서 그쵸 findAllBySellerId 해서 하든가, 아니면…findBy~(Query) → (select c from category c where c.name like “고양%”) 그러면 리스트로 개깔끔하게 받아올 수 있음.
- A-Z 상속 구현법. (동균)
1. promote 신청하면서 유저 정보를 같이 저장해야 한다. ( 이거는 promote에 @ManyToOne User 해서 유저 정보를 참조할 수 있게 하면 돼요)
- ( 두영님 ) promote 에 @ManyToOne 으로 User를 참조 할 수 있게 하면 됩니다. 저장 로직(서비스부분) 의 변경이 있을 수 있습니다. (+ DTO 등등도 변경 가능성 있음)
- 추가적으로, promote 엔티티 필드에 boolean 이나 Long 으로 이 사람의 승인신청이 완료되었는지 여부를 확인하는 필드가 필요합니다.
2. ADMIN이 promote 승인하는 로직에, Buyer 삭제 + promote 안에 있는 user 정보를 새로운 Seller 객체에 넣어서 userRepository에 save 합니다.
- ( 영민님 ) 제일 어려운데, 음…순서가 이렇습니다.
- 우리가 ADMIN Service에 만들어야 하는 로직은, 한 매서드 안에서 이루어져야 합니다.
- 로직의 실제 내용은 다음 과정을 통해 이루어 집니다.
- promote 객체에서 User의 정보를 가져와서(promoteRepository), 새로운 Seller 객체를 만들고, repository에 Save 합니다.
- 그 후 promote를 신청한 user를 userRepository에서 찾아서, 삭제합니다.
- 꼭 꼭 한 트랜잭션, 즉 한 매서드 안에서 위의 것들이 실행되어야 합니다.
3. promote 객체를 삭제해야 하는데…(boolean Long 1,2 < 안 읽음, 승인이나 등등 넣어서) 매일 몇시에 일괄적으로 불리언 TRUE 면 싹 삭제되게 하는 @Scheduled 로직 넣읍시다 어때요? ← Like에 썼던 친구 ( 지은님 )
- ( 지은님 )User → Promote → Seller 가는 그림인데, User의 안전한 삭제와 Seller의 안전한 생성을 위해 Promote가 삭제되는 시점을 늦춰야 함. 그러므로, 이 @Scheduled를 하는거임. 바로 삭제되지 말라고.
- promote 엔티티 내에서, 승인이 완료된 사람을 찾아 낼 로직이 필요합니다. 이 기준으로, 이미 처리가 완료 된 promote 객체를 모두 찾아내 삭제하는 로직으로 만들어 주세요.
