Nestjs

 @Column('varchar', { name: 'password', length: 100, select: false })

entityでuserを表示すると、パスワードを削除する設定があります.このようにすると、まずfalseに削除されます.validateUserなどの特殊な場合は、選択して個別に挿入する必要があります.
複雑なクエリーでは、通常クエリービルダーが使用されます.
query runnerでロードされたものだけがトランザクションにバインドされているので、簡単に考えている場合は、一般的にthisです.なんだか普通のクエリーばかりで、queryrunnerが持ってきたのはトランザクションばかりです.
queryRunner.manager.getRepository(エンティティ).findOne
同じように処理する
ほとんどの場合、diは常にすべてコンストラクション関数に配置され、直接属性としてインポートされる場合があります.この場合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に分かれますカスタマイズするときはnewを貼って、カスタマイズしないときは直接書きます.ParseArrayPipe({item:type,separator:“,”})
dto:タイプ、検証、ドキュメントを指定できます.pickタイプを使用してください.
typeorm
ワークスペースではcreateがcreateです
workspace.saveは本物のsave
同時に約束する必要はありません.allSettingsで処理できるのはもっと速いです.
createQuery Builderとして作成
最初からjoinテーブルを設計するよりも、query builderを作成するときにjoinを設計して実行します.
シングルsyncにしたい人はそうすべきです.
モデルジェネレータを使用している場合は問題ありません
typeormにはバグがたくさんあるので、減らしたほうがいいです.
ちょっと不思議なことに、「w.url=:url」、{url:url}という処理方法は、「w.url=${url}」を直接使用しない理由はsql注入である
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差異:2つのデータがあり、leftjoin:1つのデータの結合
outerjoin:何もない、join