week3_1일차_PR

주요 작업

• erd 재구조화 ✅ 2024-09-02
• move post api 구현 및 연결(진행중)🛫 2024-09-02
• 삭제 post api 구현 및 연결 ✅ 2024-09-02
• 수정 patch api 구현 및 연결 ✅ 2024-09-02

학습 키워드

• 클로저
• https://luxurious-share-af6.notion.site/3-1f7fcdb0591241f487bdfa6f74f1200a?pvs=4

고민 및 해결과정

ERD 설계 중 user_id의 삭제

ERD를 짜는 과정에서 계속해서 필요할까? 필요하지 않을까? 에 대한 확신을 스스로도 가지지 못했다고 생각한다.

나의 경우 기존에 username과 user_id를 따로 두는 식으로 관리를 하고, user_id의 경우 task_column에서 참조하고, todo_cards에서는 user 테이블의 username을 참조하는 방식으로 ERD를 설계했다. 하지만 이에 대해서 user_id와 username을 참조하는 곳이 다를 때, author을 username을 통해서 가져와야 하는데 username을 user의 테이블에서 가지고 올 경우 task_column의 경우는 task_columns 테이블의 col_name을 참조하면서도 user_id의 경우는 user 테이블에서 가져오는 것이 의존 관계가 서로 결합되어 두 테이블이 변경 시마다 일일이 갱신시키게 하는 것이 비효율적이라고 생각했다.

따라서 이에 대한 해결책으로 기존에 user_id를 무조건 써야 한다는 생각을 버리고 username을 중복되지 않은 기본 키로 설정한 후에 task_columns또한 username을 받고, 이를 참조하는 todo_cards 테이블 또한 task_columns 테이블만을 참조하게 하도록 의존 관계를 바꾸어 보았다.

각종 action들에 대한 history 저장 관계

기획서에는 move(이동), change(변경), submit(등록)에 대한 history가 명시되어 있다.(삭제와 같은 action도 고려해볼 만 하지만 아직은 이를 생각할 단계가 아니기 때문에 이에 대한 내용은 생략한다) 문제는 이러한 action들이 이루어질 때, 히스토리는 어느 시점에서 함께 업데이트 되어야 하는가? 에 대한 고민이 있다.

1. mysql 자체에서 트리거를 사용한 히스토리 기록
   • Mysql에서 지원하는 트리거(Trigger)은 특정 조건이 만족하면 저절로 실행되는 일종의 장치로, 한번 설정을 해놓으면 이벤트리스너와 비슷한 방식으로 동작을 계속 감시하면서 조건에 해당하는 동작이 수행되는 순간 실행되는 특징을 가진다.
   • 트리거를 사용하여 히스토리를 기록할 때, 히스토리는 자동으로 데이터베이스에 추가되기 때문에 undo, redo를 고려하는 입장에서 이를 설계해보자면
     • undo, redo를 수행하면 히스토리에서 해당하는 유저의 히스토리에서 가장 최근의 히스토리를 제거한다.
     • 히스토리가 제거될 때 실행되는 트리거를 등록하여 트리거를 통해 history의 undo를 수행한다.
     • 그러나 redo를 수행할 때는 지금 생각한 정도로는 history에 대한 History 테이블을 다시 만드는 방법밖에는 생각나지 않는데, history 테이블을 두 개 두는 것이 상식상으로는 괜찮아 보이지 않아서 고민이다.
2. 온메모리에서 deque를 통한 history 저장
   • mysql의 트리거를 사용하지 않고 따로 history에 Insert를 통해서 넣어주는 방식이다.
   • deque에서 5개의 개수제한을 놓고, action이 이루어질 때마다 하나씩 push해주되, 개수를 넘어가면 하나씩 dequeue해주면서 이에 대해 실질적으로 db에 반영해주는 방식이다.
   • 이렇게 설계할 경우, 온메모리에서 deque를 하나 두고 Undo와 redo에 대해서 action마다 수행하는 로직을 브라우저 상에 놓고 관리하게 된다.
   • 일반적으로 undo, redo는 새로고침이나 창을 나갔다가 다시 접속할 시에 없어지게 되므로, 새로고침이나 창 닫기 등의 행위를 이벤트리스너를 등록해놓고 있다가 해당 이벤트가 발생하면 flush를 통해서 모든 history의 내용을 반영하는 로직으로 작동시킨다.
     • 하지만 이러한 방식으로 갈 경우, history에 대한 예외 로직이 이루어지지 않아 만약 창을 껐을 시에 이벤트가 제대로 동작하지 않는다면 history의 갱신이 이루어지지 않으므로 이는 db의 손상을 일으킨다.
3. db에 action때마다 직접 넣되, 하나씩 빼서 undo, redo
   • 이 경우, action에 대한 api 호출을 하면서 해당 api를 처리하는 로직에서 히스토리 업데이트 + aciton에 대한 수행 자체를 하나의 트랜잭션으로 인식하여 사용해야 한다.
   • 각각의 action에 대한 히스토리의 레코드를 직접 쿼리문을 통해 넣어준다.
   • redo의 경우 undo한 것을 빼서 온메모리에서 stack 형식으로 저장하고 있다가 다시 실행할 경우 이에 대한 로직을 설계하여 다시금 돌아갈 수 있다.
   • redo의 경우 굳이 새로고침이나 창을 껐을 때, 복구시킬 의무는 없다고 생각한다. undo 또한 db에서 계속 끌어다가 복구할 수는 있겠지만은 굳이 이걸 전부 할 수 있도록 허용해주면 db에 부담이 갈 수 있기 떄문에 브라우저 내부에서 개수를 정해놓고 이를 막는 방식이 나을 것 같다고 판단했다.
   • 나는 히스토리와 action의 수행이 하나의 트랜잭션으로 판단해야만 정상적인 db의 갱신이 이루어지기 때문에 이 방식이 제일 합리적이라고 생각한다. 아직까지는 세 가지 고민을 하면서 구현중인데, move까지 구현이 된다면 이에 대해서 history를 다시금 생각해보고 구현 및 연결할 예정이다.