TypeORM 쓰면서 곰곰히 생각해보니까,
decorator 를 쓰면 정작 타입 안정성을 보장할 수 없어서,
종국에는 typescript 쓰는 의미가 없어지더라.
그래서 처음에는 decorator 를 보완할 방법이 없을까 곰곰히 생각해보다가,
타입스크립트 고유의 템플릿 (제네릭) 메타 프로그래밍 사용하면,
decorator 를 쓸 필요도 없이 훨씬 타입 안전한 ORM 을 만들 수 있지 않나 싶더라
짤처럼 테이블이랑 각 클래스 멤버 변수 정의해주면,
해당 타입을 해석해서 그에 맞는 테이블 자동으로 생성해주는 ORM 만들거임
가령 저기서 변수 payment_cycle 의 경우,
typescript 의 타입은 "ONCE"|"MONTH"|"YEAR"|null 이라는 literals or null 타입이 되면서
DB 테이블의 컬럼 타입은 `VARCHAR DEFAULT NULL` 이 됨
이 정도면 ㄹㅇ 사용하기 편할거 같지 않냐?
구현 가능 여부 테스트해봤는데, typescript-is 나 ts-node 컨셉 잘만 활용하면
올해 안에 완성 가능할 거 같다. 고로 올해에는 이거나 만들어야지
편리하다기엔 문서가 불친절하다는 인상을 받았는데… 내 창의력 때문에 그랬는진 몰라도. 암튼 그 코드 덩어리를 수술하다니 조금 리스펙. 근데 MySQL에서 썼을 땐 snake case로 테이블 잘 생성하던데 다른 DB는 상황이 다른 건가.
아까 저 글 쓰고 typeorm 개조하다가, 현자타임 와서 다 엎고 새로 만들기로 함. 다시 생각해보니 typeorm 은 typescript orm 인데, 정작 typescript 의 타입 검사를 이용할 수 없는 끔찍한 혼종이었음. 글 내용도 수정했으니 확인 후 의견 주시면 ㄳ ㄳ
되면야 좋아보임. 근데 내가 추측하기론 데코레이터를 쓰는 이유가 타입 정보는 런타임에 남길 수 있는 정보가 아니라서 런타임에 정보를 남기려고 쓰는 거라 완전히 없애긴 힘들지 않을까 생각. 그리고 typeorm베이스로 하면 쿼리 빌더 쓸 때 타입 정보 많이 날아가는 문제 그대로 가져올 것 같아서 그 부분 좀 슬플 것 같음.
아 다시보니 아예 typeorm 안 쓰기로 했구나. 오히려 잘 된 결정이네.
sequelize는 어땠음?
그건 ㄹㅇ 타입스크립트에서 쓰기 힘듬
시퀄라이즈 ts 지원하지 않냐 인터페이스 구림?
타입스크립트 타입정보 꽤 괜찮게 읽어들이는 라이브러리 있었는데 그걸써야할걸 리플렉트 메타데이터랑 기본 컴파일러가 지원하는 기능만으로는 구현못함