Nest typeorm

 @DeleteDateColumn()
 이것과
 @Column('date',{()=>"CURRENT_TIMESTAMP}) 과 동일함

이런거는 공식 문서를 봐야 알 수 있음

autoLoadEntities는 TypeOrmModule.forFeature에 든 엔티티만 자동으로 연결함
가장 바깥에 없으면, migration시 에러가 생길 수 있음

이때 ormconfig같은 걸로 분리하지 않고,
그냥 app module에 바로 설정을 했을 경우에 process.env가 읽히지 않는 현상이 나옴
그 이유는 config module 이 생성되기 전에 이미 만들어져버리기 때문임.

해결 방법은 forRootAsync라는 걸로 바꾸고,

forRootAsync({
	inject:[ConfigService],
    useFactory:async()=>{
    	return(
        	type:"mysql")

같은 느낌으로 바꿔줘야 함

typeorm seeding, migration
typeorm seeding, faker 같은 라이브러리로 시딩을 할 수 있음

table에 migration이라는 것을 사용해서 소스 코드로 한 번에 작업하는 방법
롤백도 가능함
npx typeorm migration:create -n categoryToType 이런식으로
npx typeorm migration:generate -n categoryToType 같은 것을 보고서 entity를 수정하면 알아서 처리할 수 있음
npm run typeorm migration:generate -- -
에서 typeorm 은 단순한 typeorm 이 아니라
"typeorm": "ts-node --require tsconfig-paths/register ./node_modules/typeorm/cli.js",
이 명령어라는 점
기존 dto를 카피해서 picktype으로 가져올 수 있음 swagger의 부분에 있음
nestjs 공식문서에 openapi/ partial types에서 가면 됨

db 역시 di를 해줘야 함. table이 entity
container=>service=>repository=>entity 서비스는 repository를 통해서 entity에 쿼리를 날린다는 느낌
repository를 만들어 주는 이유. 거기다가 di를 쓰는 이유는 테스트의 용의성이 가장 큼
용의성이 repository를 di로 테스트시 바꿔주면 실제 db가 아닌 그냥 object에 써먹을 수도 있고, 훨씬 간단해짐

dto단으로 검증하는 것이 아니라면 service단에서 그냥 throw new error로 뱉어버릴 수 있음
repository 는 import 에다가 TypeOrmModule.forFeature([엔티티 명])로 넣음
async는 promise 안에서 throw 하는 경우 그냥 아무런 문제가 없이 정상적으로 해결된 느낌으로 처리해버림. return undefined 처리가 됨.
그래서 exception handler로 처리해야 됨.