일정 관리 과제 회고

Field 'name' doesn't have a default value 오류

과제를 진행하던 중 name 필드에 값이 없다는 오류 메시지를 마주쳤습니다. Writer 테이블이 생성되기 전 name 필드를 통해 사용자 정보를 구별하고자 했으나, 동명이인 문제로 Writer 테이블을 만들게 되었습니다. 그러나 기존에 JPA를 사용하면서 Entity에서 삭제만 시켜두면 적용되었던 것에 익숙해져서 그런지 Schedule.sql에서 name을 삭제하지 않아 NOT NULL 제약으로 인해 오류가 발생했습니다. 이를 통해 데이터베이스 구조 변경 시 관련 필드와 로직을 함께 검토해야 한다는 교훈을 얻었습니다.

 

scheduleRepository에서 Writer 객체 사용

다음으로, scheduleRepository에서 Writer 객체를 파라미터로 받아야 할지에 대한 의문이 생겼습니다. Schedule 테이블과 Writer 테이블 간의 관계는 N:1로 설정되어 있었기에, Schedule에 대한 Repository에서 Writer를 받아도 괜찮을지 고민되었습니다. 그러나 제가 내린 결론은, Schedule 객체가 작성자 정보를 알고 있으므로 Writer 객체를 매개변수로 사용하는 것이 문제가 없겠다는 것이었습니다.

 

응답 구조 커스터마이징

세 번째 문제는 페이지네이션 관련 응답 구조였습니다. 페이지네이션 정보가 포함된 응답을 반환하는 과정에서, 불필요한 데이터가 많아지자 이를 줄이고자 했습니다.

"pageable": "INSTANCE",
    "last": true,
    "totalPages": 1,
    "totalElements": 0,
    "first": true,
    "size": 0,
    "number": 0,
    "sort": {
        "empty": true,
        "sorted": false,
        "unsorted": true
    },
    "numberOfElements": 0,
    "empty": true

위와 같은 페이지네이션 정보들이 주어지는데, 실제 협업할때는 필요하겠지만, 지금 당장은 불 필요한 정보이므로 과감히 없애고자 하였습니다. 페이지 객체 대신 필요한 데이터 리스트만 반환하도록 변경하여 응답을 간소화했습니다.

 

Schedule 및 Writer 동시에 업데이트

마지막으로, Schedule의 task와 updated_at을 업데이트할 때, Writer의 name도 함께 업데이트해야 할지 고민하게 되었습니다. 처음에는 각각을 업데이트하는 방식으로 접근했으나, 이는 비효율적이라는 생각이 들었습니다. 그래서 Writer 정보는 Schedule이 이미 알고 있으므로, 따로 업데이트할 필요가 없다는 결론을 내렸습니다. 이를 통해 코드의 복잡성을 줄일 수 있었습니다.

 

Update 응답에 대한 의문

Update가 성공했을 때 어떤 응답을 보내야 할지에 대한 의문이 들었습니다. 제 생각은 상태 코드만 전달하고, 프론트에서 이를 기반으로 처리하는 것이었습니다. 하지만 실제 운영 서비스에서는 업데이트된 정보를 응답으로 보내주는 것이 좋은지, 아니면 상태 코드만 보내주는 것이 더 나은지 궁금해졌습니다. 이 부분에 대한 적절한 접근 방식에 고민이 들었습니다.