-
아직 많이 부족하게 느껴지는 TreeRepository 함수. 생각보다 유용한 함수는 없었다.
-
mpath 컬럼에 NOT NULL 제약조건을 걸 수 없다.:
mpath는 본인의 id를 포함한다. typeorm은 이를 작성하기 위해 insert 후, update한다. 따라서 실제 데이터의 mpath는 null이 없지만, 일시적으로 null 값을 가질 수 밖에 없기 때문에 NOT NULL CONSTRAINT를 걸 수 없다. -
mpath는 isVirtual 속성의 기본값이 true이다. nest에서 entity내에 @Column() 데코레이터를 작성하면 아래처럼 두번 mpath가 검색되고, 제외하면 return되는 entity에 포함되지 않는다.
SELECT id, parent_id, mpath, mpath FROM table- 아래 처럼 직접 metadata를 변경하면 결과에 포함된다.
entityName.metadata.columns.find(x => x.databaseName === 'mpath').isVirtual = false
// 출처: https://github.com/typeorm/typeorm/issues/4232- 일반 entity에 포함된 treeEntity는 저장될 때, parent가 없는 데이터는 실제 부모가 없음에도, 상위 entity(gardenEntity)를 부모로 잘못 인식하여 mpath가 비정상적으로 저장된다.
PARAMETERS: ["undefined251.",251]
const tree: TreeEntity = { name: string }
const garden = new gardenEntity({ name: string, age: number, trees: [tree] })
repository.save( entity )코드(OOP)보다 RDB사고가 더 익숙한데, typeORM을 하다보니 여간 불편한게 아니다.
logging: true로 쿼리를 확인하면서 이게 뭐하는 짓이야!!!!!!!!!!! 싶을때가 한 두번이 아니고,
간단하게 쿼리로 작성하면 될 것을 왜이렇게 돌아가야하나.. 분노가 치밀어 오른다.
하지만 처음으로 라이브러리 내부도 자세히 들여다 볼 줄도 알게되고, 이런 계기로 다들 오픈소스에 손을 대는거구나.. 처음으로 느꼈다. 아직은 중간중간 도대체 어디서 어떻게 연결되는건지 코드가 끊키지만, 그래도 어떠면 나도 기여할 수 있겠구나. 하는 자신감도 생겼다.(?!)
남들이 다 짜놓은 줄 알았는데 추가할 수 있는 기능은 참으로 무궁무진한거 같다...ㅎㅎ
정말이지 애증으로 남을 typeORM -.ㅠ
