클론 코딩 [ 15주차 ]

연달아 작성하는 15주차입니다.

15주차에는 아주 큰 일이 있었는데요.. 있었던 내용들은 한 번 정리해보도록 하겠습니다.

🎉　Done

1. 임시 저장 기능 설계

• velog 방식

1) 동일한 테이블에 임시 저장용 포스트 정보도 저장
2) is_temp 플래그로 구분하고, original_post_id를 저장

• 구현하고자 하는 방식

1) 별도의 테이블에 임시 저장용 포스트 정보 저장
2) is_temp가 아닌 has_temp로 플래그 사용하고, temp_post_id를 저장

• 이유
  

위 버튼을 통해 수정 페이지 진입

수정 시 임시 포스트가 있을 경우 내용을 불러올 것인지 팝업 호출

• 팝업 이미지

• 예상되는 절차
  • 포스트 테이블에서 동일한 slug를 가진 포스트 가져옴
    
  • 두 개 이상일 경우 is_temp가 없는 포스트 로딩
  • 팝업에서 yes 클릭 시 is_temp=true인 포스트 내용으로 교체
• 동일한 테이블에 동일한 slug를 가진 포스팅이 하나 더 생기는데 이러면 하나의 테이블에서 slug는 유니크하다는 현재의 가정이 깨짐

따라서 임시 포스팅을 저장하는 별도의 테이블을 두고, original posting에 temp 데이터가 있는지 확인하는 방식으로 가려고 함

2. DB 인스턴스 복구 작업

이번주에는 아주 큰 일이 있었는데요..

DB 인스턴스가 모조리 날아가는 문제가 있었습니다.

2-1. 예상 원인 (Free-trial 기간의 종료와 instance 생성 시 config 오류)

• 12월에 만료된 30일 간의 Free-trial
  
• 유예기간을 줌
  
• 인스턴스 설정 (추정...)
  • 이미 무료인 VM 생성 (아마 2개 까지..?)
    
  • 그러나 그 안에 함정
    
  • 아마도 intel로 CPU 설정..?
    

2-2. 완전 수동 복구

postgresql 재설치 및 방화벽 세팅, db 테이블에 데이터까지 모두 수동으로 삽입했씁니다..

• 유저 테이블
  
• 포스트 테이블
  
• 이미지 테이블
  

... 정말 다하고 나니 현타가 씨게 왔습니다.

3. DB 인스턴스 복구하며 BLOG_USERS 테이블 스키마 변경

• 발단의 시작

Q1) user_id가 반드시 필요한가?

user_name을 유니크하게 가져간다면 별도의 id는 필요 없음.

그러나 user_id를 내부적으로 사용하고, user 테이블을 별도로 두는 경우

id에 대한 user의 이름을 알기 위해 join을 하는등 로직이 조금 복잡해짐.

따라서 user_id를 컬럼에서 제거하고 user_name을 바로 사용하도록 변경

Q2) post_id도 반드시 필요한가..?

• velog는 포스팅 수정 페이지에서 post_id 사용
• user 보다 join할 일이 매우 적음

📝　To-Do

1. Posting 데이터, 이미지 추가하기

2. 임시저장, 출간하기, 업데이트 서버 API 구현

3. Toolbar 설계