Claim adventure boss reward

[U-lis]

• Fix wrong reward logic
• Collect and give rewards

[ipdae]

임시모델이라 생각해서 넘어갔던 부분인데 점점 사용하는쪽으로 굳어가는듯하여.. 현재 직렬화 방식 특성상 nullable 필드는 최대한 지양하는게 좋을것 같습니다. 별도 상태로 모아다 저장하거나, nullable이 필요하다면 순서를 정렬해둬서 List길이별로 해석이 되게 만드는게 좋을것같습니다. 추가로, int타입은 .Serialize를 부르면 문자열(Text)로 저장하고 있는데 직렬화시점에 따로 .Serialize를 부르지않고 해석하는 시점에 (Integer)로 캐스팅해서 쓰는게 좋을것같습니다.

[U-lis]

임시모델이라 생각해서 넘어갔던 부분인데 점점 사용하는쪽으로 굳어가는듯하여.. 현재 직렬화 방식 특성상 nullable 필드는 최대한 지양하는게 좋을것 같습니다. 별도 상태로 모아다 저장하거나, nullable이 필요하다면 순서를 정렬해둬서 List길이별로 해석이 되게 만드는게 좋을것같습니다. 추가로, int타입은 .Serialize를 부르면 문자열(Text)로 저장하고 있는데 직렬화시점에 따로 .Serialize를 부르지않고 해석하는 시점에 (Integer)로 캐스팅해서 쓰는게 좋을것같습니다.

nullable 에 대해서는 저도 신경이 좀 쓰이기는 하는데, 이게 FAV 같은건 애초에 null 을 넣어두는게 나증에 제일 속편해서.. 그리고 int 같은거 serialize 하는거랑 그냥 저장해서 int 로 casting 하는거랑 뭔가 성능 차이같은게 있는걸까요? 하다가 보니 어떤건 (Integer) 하고 어떤건 ToInteger() 하는게 헷갈려서 다 통일한거였습니다.

[ipdae]

nullable 에 대해서는 저도 신경이 좀 쓰이기는 하는데, 이게 FAV 같은건 애초에 null 을 넣어두는게 나증에 제일 속편해서..

FAV자체가 null을 지원안했던걸로 기억하는데, 없으면 null이란식으로 무시하고 넘어갈수있지않을까요?

그리고 int 같은거 serialize 하는거랑 그냥 저장해서 int 로 casting 하는거랑 뭔가 성능 차이같은게 있는걸까요? 하다가 보니 어떤건 (Integer) 하고 어떤건 ToInteger() 하는게 헷갈려서 다 통일한거였습니다.

실제 성능상 차이가 있고(내부적으로 gc를 유발하는걸로 알고 있습니다.), ToInteger() 를 호출하는건 사실 기존 직렬화 방식이 잘못 적용된 레거시라 그렇습니다. 가급적이면 캐스팅을 쓰는게 맞습니다.