WIL 최종프로젝트 1주차

2023.06.12 월 <-일요일에 써야 했는데

 

최종프로젝트 1주차가 끝났습니다.

깍두기 시간이라고 서로 알아가며, 천천히 알아가는 그런 시간을 가집시다~ 했지만, 모두 의욕이 대단하셔서, 후다닥 일이 진행되고 있습니다.

 

금~일요일 동안 고민했던 부분은 예약부분이였습니다. 이전 TIL에서 생각한 예약시스템을 구현하면서 좀 어려운 부분을 만났고 금요일이 끝났었습니다.

토요일에는 그에대한 좀 더 본질적인 문제를 파악하고자 했습니다.

의문점 
1. 형태가 같은데 굳이 티켓데이터가 여러 개가 필요할까
2.티켓을 꼭 자동으로 생성해야할 이유가 있을지

 

예약 3일전에 자동적으로 일정한 형식에 맞춰 티켓이 생성되고, 예약은 공연 시작 3일 전부터 열리며, 예약 가능인원만큼 예약가능한 티켓이 같은 형태로 db에 저장되고 티켓이 예매될 때마다, 티켓 상태를 False로 바꾸고 모든 티켓의 상태가 False일 때, 매진이 되어 예매를 더 이상 진행할 수 없는 그런 로직을 구현해야 하는가에 대한 의문의 결과는 그럴 필요가 있을까 였습니다.

 

첫번째 의문은 Ticket모델을 변경시켜 해결했습니다.

class Ticket(models.Model):
    author = models.ForeignKey(User, on_delete=models.CASCADE)
    event = models.ForeignKey(Event, on_delete=models.CASCADE)
    event_date = models.DateField()
    event_time = models.CharField(max_length=11)
    ticket_status = models.BooleanField(default=True)
    booked_users = models.ManyToManyField(User, related_name="booked_tickets")
    current_booking = models.PositiveIntegerField(default=0)

크게 변경된 것은 없지만, Event 모델과 Ticket 모델을 분리시켰습니다.

상속을 통해 사용하니 에러가 발생하였습니다.

Segmentation fault

여러 이유에서 나온다고 하는데, 처음 에러의 원인이다 생각한 부분은 JSON필드를 사용하는 time_slots필드였습니다.

이리저리 수정하여, 이제 완벽하다 생각하여, 다시 runserver를 돌렸지만 Segmentation fault 에러가 다시 발생하였습니다

https://codingfriend.tistory.com/18

[오류] segmentation fault 원인

 

에러에 대한 hint도 없어, 일단 작업한 것을 다른 곳에 저장하고, 작업내역을 취소하고 파일단위로 다시 추가하며, 원인을 찾았습니다.

 

원인은 모델에서 발생하였습니다. Ticket 모델을 넣고 runserver를 돌리니, 바로 Segmentation fault가 출력되었습니다.

 

이리저리 알아본 결과 drf에서는 상속을 사용하지 못하다는 식의 글을 보았습니다. 일단 Ticket 모델을 Event모델을 상속하지 않는 형태로 변경하고 runserver를 사용하니 Segmentation fault 에러는 해결하였습니다.

 

아마, import나 사용방식이 달라 발생한 에러였던거 같습니다. 상속하여 사용했다는 글을 보고 상속하는 형태로 모델을 구현한 것인데, 이 부분에 대해서는 조금 더 공부가 필요할 거 같습니다.

 

형태가 같은 티켓을 db에 저장시키는 것은 db에 부담이 간다 생각했고, 그에대한 해결책도 구했지만, 어디까지나, 생각했던 가능범위는 하나의 공연이 기준이였습니다, 5~6개의 공연에 수용가능인원이 100명이 넘어가고, 하루에 공연시간도 3타임 있다고 생각하면, 1800개의 정보가 생겨버립니다. 

이걸 생각하니 순간 아찔하더군요. 그래서 최대한 db에 무리를 주지 않는 방식을 생각하여 구현하였습니다.

 

두 번째 의문은 CRUD를 생각하여, 해결하였습니다.

꼭 자동화가 필요없다 생각했습니다. 현업의 상황은 아직 잘 모르지만, 공연 개시도 관리자가 하는데 티켓 생성도 관리자가 하면 안되는 이유가 없습니다.

티켓을 상품이라 생각한다면, 온라인쇼핑몰에서 상품을 생성하고, 사이트에 올리는 것 또한 관리자가 합니다.

여기서 중요한 포인트는 관리자가 하는 것과 일정한 형식을 가지고 등록한다는 점이였습니다.

그렇기에 기존의 자동화 시스템 구현은 포기하고, CRUD를 사용하여, 티켓을 구현하는 방법을 생각하여 해당 문제를 어느정도 해결하였습니다.

(자세한 구현은 오늘 TIL에서!)

 

느낀점

최종 프로젝트 1주차를 보냈습니다, 각자 맡은 역할에 충실하고, 서로 의사소통을 나누는 것 또한 아주 편안하게 진행됩니다.

이렇게 좋은 팀인 만큼 제가 맡은 역할에 최선을 다하고 싶다는 생각이 듭니다. 그래서 그런지 이번 예매를 구현할 때, 좀 더 좋은 방법이 없는지, 어떻게 구현할지 많은 고민을 하였고 어느정도 그 답을 찾은 거 같아 뿌듯합니다.