@Column('varchar', { name: 'password', length: 100, select: false })entity 안에 user을 보면, password를 빼버리는 설정이 있음. 이러면 일단 false로 빼버리기에, 특수한 경우 즉 validateUser같은 경우에서는 select 해서 따로 넣어줘야 함
복잡한 쿼리는 쿼리 빌더를 사용하는 경우가 많음
query runner를 통해 불러온 것들만이 transaction에 묶여서 되게 단순하게 생각했을 때, 일반 this.어쩌구로 가져온 것은 전부 다 일반 쿼리, queryrunner로 가져온 것들은 transaction임.
queryRunner.manager.getRepository(엔티티).findOne
같은 방법으로 처리 가능
항상 constructor에 di를 다 넣는 경우가 대부분이었는데, 그냥 property 로 가져오는 경우도 있음. 그런 경우는 childservice가 상속받아서 쓸 때 di가 안 되는 경우가 있는데, 이때만 밖에다 하는 것을 권장함
사실 쿼리의 가장 기본은 find에다가 take 1이 기본이고, take 1 대신에 findOne where id 인데 여기서 더 나아가면 findOneById로 찾는 방법이 있음
sequelize는 include 안에 조건을 적는 과정인데, include를 제거 하고 바로 할 수 있다는 장점이 있음
param 이나 query는 다 +나 parseInt로 바꾸거나, ParseIntPipe를 이럴 때 쓴다
parameter를 생각해 보면 :id 로 받았을 때 1,2,3같은 그런 느낌으로 조회를 하는 경우가 있음. 이것은 string이기에 "1,2,3" 으로 나오지만 ParseArrayPipe라는 거를 통해서 array로 쪼갠다. customizing을 하는 경우에는 new를 붙히고, 아닌 경우는 그냥 작성함. ParseArrayPipe({item:type,separator:","})같은 느낌으로 처리 가능
dto : 타입 지정, validation, 문서 다 가능함 pick type을 써라
typeorm
workspace에서 그냥 create는 그냥 create라는 것
workspace.save가 진짜 저장임
await은 항상 동시에 할 필요 없이 promise.allSettled로 처리할 수 있는 것이 훨씬 빠르다는 거
createQueryBuilder로 작성하기
처음부터 join table을 설계하는 것 대신, query builder로 만들 때쯤 join을 설계하고 가는 것이 좋음.
단 sync로 만드는 것을 원하는 사람들은 그렇게 해야 함.
model generator를 하는 경우에는 없어도 문제가 없음
typeorm은 many to many에 버그가 많기에 줄이는 것이 좋음
조금 신기한 것 'w.url=:url',{url:url}이런 방식으로 처리하는 방법인데, 그냥 바로 'w.url=${url}'로 하지 않는 이유는 sql injection 때문임
get Many나 getRawMany뭐 이런 것들 에서 Raw는 훨씬 db출력에 가깝다는 느낌은 있음
join: {
alias: 'workspace',
innerJoinAndSelect: {
channels: 'workspace.Channels',
},
},
//relations:[Channels]이렇게 하거나 저 relations 부분과 같음
this.workSpacesRepository.createQueryBuilder('a').innerJoinAndSelect('workspace.Channels','challens').getOne();
'a'부분은 alias 부분임 같은 것으로 처리 가능
typeorm 은 join하면 그냥 단순하게 join만 함. 거의 안 가져오고, and Select를 붙혀야 그 뒤에 붙은 것들을 가져옴
innerjoin, leftjoin 차이 : 양쪽 데이터 있는 것, leftjoin : 한 쪽에 있는 것 조인
outerjoin : 아무 것도 없는 것에도 관계 없이 join
