시간표를 만들 때, 해당 학기에 대표 시간표가 없는 경우 is_primary 필드를 true로 설정

[Jhvictor4]

조회가 아무래도 잦긴 할 것 같아서 배치가 나을 것 같은데, 넣을 지점이 어딘가 따라 다를 것 같슴다 어디 생각하는 곳 있어?

[davin111]

@Jhvictor4 너 질문 의도가 is_primary = true 로 언제 넣어줄 거냐, 라는 시점의 얘기인 거 같은데. 내 말은 그냥 is_primary 는 계속 nullable 한 필드로 가져가고, 친구한테 대표 시간표 보여지는 시점에, 없으면 api 응답으로 가장 오래된 거 주면 끝 아닌가, 라는 거였어. 굳이 db 업뎃 칠 필요 없이. is_primiary = true 는 유저가 직접 설정한 경우만 세팅하고.

[Jhvictor4]

@davin111 근데 여기서 대표시간표 내려줘야 해서 조회 일어날 떄 primary 체크를 해줘야 하긴 해 그런 관점에서는 명시적으로 하나 존재하는게 나을 것 같다 생각함

[davin111]

@Jhvictor4 저거 뿌릴 때도 로직으로 계산해서 표시해 줘도 되긴 하지 않나 싶긴 한데 흠... 어차피 뿌리려고 다 조회하니까. 대표 시간표를 디폴트로 선정하는 로직 (예를 들어 가장 오래된 게 아니라 가장 최근에 생성한 걸로 한다) 이 바뀔 때 더 유연하게 대응할 수 있는 장점도 있긴 하고.

아무튼, 그럼 너 말대로 한다면 과도기 기간에만 is_primary 를 nullable 로 두고, db batch 돌리는 작업 하고 나면, not null 로 spring snu4t 에서 관리하는 걸로 바꾸면 좋을 듯.

최종 고민해서 결정하고 알려주시죠.

[Jhvictor4]

아 근데 이ㅓㄱ.. 배치든 조회시점 계산이든 table 독에 createdAt 필드가 없네.. 그럼 가장 먼저 들어간 걸 어떻게 알지?

신뢰할 수 없지만 ObjectId order로 갈게

[davin111]

@Jhvictor4 ㄷㄷㄷ… timetable 에 created_at 넣는 건 어쨌든 나중에 필요할 수 있겠다 ㅜ

어떻게 보면 기존 데이터에 대해서는 불가능한 스펙이었네. id 는… 최소한의 경향성이라도 생성시점과 순서가 일치하는 게 맞나? 아예 랜덤은 아니고?

[Jhvictor4]

ObjectId 바이트 상단부가 unix timestamp라 거의 유사하게 정렬될 것 같긴 한데 초 단위까지이고 & 하위 바이트가 프로세스가 다르면 사실 상 랜덤이라서 정확히 믿을 수는 없을 것 가틍ㅁ 시간표는 insert 잦지 않고 거의 기대대로 동작할 것 같은데 가령 파드 엄청 많은 곳에서 실시간 채팅 같은 데이터를 쌓는다 하면 아예 신뢰 불가능할 듯 싶음

[davin111]

@Jhvictor4 오 ㅎㅎ 설명 넘 감사. 요거 pr 제목 바꿔서 머지하면 좋을 듯!