TypeORM: entity, DataSource, Repository, QueryBuilder va migratsiyalar

Qisqacha: TypeORM — jadvalni dekoratorli klass (entity) sifatida yozadigan ORM: @Entity, @Column, @ManyToOne. Ulanish va sozlama — DataSource, so'rovlar — Repository (find, save, delete) yoki SQL'ga yaqin QueryBuilder. NestJS dunyosida hali ham keng tarqalgan. Eng katta tuzog'i — synchronize: true: biz o'lchadik, ustun turini o'zgartirsangiz TypeORM DROP COLUMN + ADD qiladi va ma'lumot yo'qoladi. Prodakshnda sxema faqat migratsiya bilan o'zgaradi.

Bu darsda

• TypeORM entity'ni dekoratorlar bilan yozasiz va u qanday jadvalga aylanishini ko'rasiz.
• DataSource, Repository va QueryBuilder bilan o'qish va yozishni bajarasiz.
• Relation'lar (@ManyToOne, @OneToMany), relations va eager farqini tushunasiz.
• synchronize nega prodakshnda taqiqlanishini haqiqiy natijada ko'rasiz.
• migration:generate, migration:run, migration:revert buyruqlarini ishlatasiz.

Oldin bilishingiz kerak: ORM, query builder va raw SQL, Legacy dekoratorlar va reflect-metadata, Kysely va Knex query builder'lari, Foreign key va referential actions.

1. Nega bu kerak?

Sardor ishga kirdi. Birinchi kuni unga 2021-yilda yozilgan NestJS loyihasini berishdi. Fayllarni ochadi — user.entity.ts, order.entity.ts, har birida @Entity(), @Column(), @ManyToOne(). Prisma'dagi schema.prisma ham, Drizzle'dagi pgTable ham yo'q. Bu — TypeORM.

Prisma kursning asosiy tanlovi bo'lsa ham, TypeORM'ni tanish shart. Sabablari oddiy:

• NestJS hujjatlari uzoq yillar TypeORM'ni birinchi o'ringa qo'ygan. Minglab loyihalar shu bilan yozilgan.
• Java (Hibernate) yoki C# (Entity Framework) dan kelgan dasturchilar aynan shu uslubni yaxshi ko'radi.
• Eski loyihani qo'llab-quvvatlash — kichik jamoalarda eng ko'p uchraydigan ish.

O'xshatish: Prisma — zamonaviy avtomat mashina, TypeORM — mexanik uzatmali mashina. Ikkalasi ham yuradi. Lekin mexanikada qachon debrizka bosishni bilmasangiz, mashina o'chib qoladi. TypeORM'ning "debrizkasi" — synchronize va relation'lar. Bu darsda aynan shularni o'lchaymiz.

Maslahat: Bu darsdagi hamma natijani biz o'zimiz ishga tushirdik: TypeORM 1.1.2, pg 8.23.1, TypeScript 6.0.3, Node 24.21.0, PostgreSQL 17.6, Windows 11 (2026-10-25). Kanonning tezlik o'lchovlari esa ORM, query builder va raw SQL darsidagi katta bazasida olingan.

2. Entity: jadval — klass ko'rinishida

2.1 Birinchi entity

Entity (mohiyat) — bazadagi bitta jadvalni ifodalaydigan klass. Har xususiyat (property) — ustun. Har obyekt — bitta qator.

TypeORM entity'ni dekoratorlar bilan tavsiflaydi. Dekoratorlarni 15-qismda o'rgangan edik (Legacy dekoratorlar). TypeORM aynan legacy dekoratorlardan foydalanadi: tsconfig.json da ikki sozlama shart.

{
  "compilerOptions": {
    "experimentalDecorators": true,
    "emitDecoratorMetadata": true,
    "strictPropertyInitialization": false
  }
}

emitDecoratorMetadata — TypeScript har xususiyatning turini (string, number) metama'lumotga yozadi. TypeORM shu orqali @Column() ning turini biladi. strictPropertyInitialization: false — aks holda email: string; qatoriga "boshlang'ich qiymat yo'q" xatosi chiqadi.

Bizning vazifalar domenidagi uchta entity (src/entities.ts):

import {
  Entity, PrimaryGeneratedColumn, Column, ManyToOne,
  OneToMany, CreateDateColumn, Index, JoinColumn,
} from "typeorm";

@Entity({ name: "foydalanuvchilar" })
export class Foydalanuvchi {
  @PrimaryGeneratedColumn()
  id: number;

  @Column({ unique: true })
  email: string;

  @Column({ name: "toliq_ism", length: 100 })
  toliqIsm: string;

  @OneToMany(() => Vazifa, (v) => v.egasi)
  vazifalar: Vazifa[];
}

@Entity({ name: "vazifalar" })
export class Vazifa {
  @PrimaryGeneratedColumn()
  id: number;

  @Column({ type: "text" })
  matn: string;

  @Column({ default: false })
  bajarildi: boolean;

  @CreateDateColumn({
    name: "yaratilgan_vaqt", type: "timestamptz" })
  yaratilganVaqt: Date;

  @Index()
  @ManyToOne(() => Foydalanuvchi, (f) => f.vazifalar, {
    nullable: false, onDelete: "CASCADE",
  })
  @JoinColumn({ name: "egasi_id" })
  egasi: Foydalanuvchi;

  @OneToMany(() => Izoh, (i) => i.vazifa)
  izohlar: Izoh[];
}

Izoh entity'si xuddi shunday: id, matn va @ManyToOne(() => Vazifa) + @JoinColumn({ name: "vazifa_id" }).

Har dekorator nima qiladi:

name: "toliq_ism" ga e'tibor bering. JS'da toliqIsm (camelCase), bazada toliq_ism (snake_case). Prisma'dagi @map bilan bir xil g'oya.

2.2 Node type stripping dekoratorni bajarmaydi

24-qismda Node 24 .ts faylni o'zi ishga tushirishini ko'rgan edik (type stripping). Lekin u faqat turlarni o'chiradi. Dekorator — tur emas, ishlaydigan kod. Kanon tajribasi buni aniq qayd etgan: dekoratorli entity Node type stripping'da ishlamadi, shuning uchun kanon o'lchovi dekoratorsiz EntitySchema shaklini ishlatdi.

Shuning uchun TypeORM loyihasi odatda avval kompilyatsiya qilinadi (tsc → dist/), keyin node dist/...js. Biz ham shunday qildik.

Tekshirib ko'ring: @OneToMany qo'yilgan vazifalar xususiyati uchun bazada ustun bormi?

3. DataSource va synchronize

3.1 Ulanish

DataSource — TypeORM'ning markaziy obyekti: ulanish ma'lumotlari, entity'lar ro'yxati va sozlamalar. Prisma'dagi PrismaClient, Drizzle'dagi drizzle(pool) o'rnida.

import { DataSource } from "typeorm";
import { Foydalanuvchi, Vazifa, Izoh } from "./entities.js";

const ds = new DataSource({
  type: "postgres",
  url: process.env["DATABASE_URL"],
  entities: [Foydalanuvchi, Vazifa, Izoh],
  synchronize: false,            // prodakshnda HAR DOIM false
  logging: ["query", "schema", "error"],
});
await ds.initialize();           // hovuz ochiladi, metadata quriladi
// … ish …
await ds.destroy();              // hovuz yopiladi

logging: ["query"] — har SQL so'rov konsolga chiqadi. O'rganish paytida doim yoqing: ORM nima yuborayotganini ko'rmasdan uni tushunib bo'lmaydi.

3.2 synchronize: true — bo'sh bazada

synchronize: true — "entity'larga qarab bazani o'zing moslashtir". Biz bo'sh bazada ishga tushirdik. TypeORM yuborgan DDL (qatorlar telefon uchun bo'lindi, mazmuni aynan):

CREATE TABLE "foydalanuvchilar" (
  "id" SERIAL NOT NULL,
  "email" character varying NOT NULL,
  "toliq_ism" character varying(100) NOT NULL,
  CONSTRAINT "UQ_56243fb8509f85cdc96db3bb380" UNIQUE ("email"),
  CONSTRAINT "PK_7a1a5c53a07b3d9e528cc248a9a" PRIMARY KEY ("id"));
CREATE TABLE "vazifalar" (
  "id" SERIAL NOT NULL, "matn" text NOT NULL,
  "bajarildi" boolean NOT NULL DEFAULT false,
  "yaratilgan_vaqt" TIMESTAMP WITH TIME ZONE NOT NULL
    DEFAULT now(),
  "egasi_id" integer NOT NULL,
  CONSTRAINT "PK_88a44a87ee9bc6e784a4a61ea38" PRIMARY KEY ("id"));
CREATE INDEX "IDX_8a0fd84031238a1ec27d9f75cd"
  ON "vazifalar" ("egasi_id");
ALTER TABLE "vazifalar" ADD CONSTRAINT
  "FK_8a0fd84031238a1ec27d9f75cd4" FOREIGN KEY ("egasi_id")
  REFERENCES "foydalanuvchilar"("id")
  ON DELETE CASCADE ON UPDATE NO ACTION;

Uch narsaga qarang:

• SERIAL va integer — 26-qismda biz bigint GENERATED ALWAYS AS IDENTITY ni tanlagan edik (Primary key tanlovi). TypeORM sukut bo'yicha eski SERIAL ni oladi.
• Cheklov nomlari — hash: UQ_56243fb8…, FK_8a0fd840…. Xato xabarida shu ko'rinadi. 26-qismdagi vazifalar_egasi_id_fkey kabi o'qiladigan nom yo'q.
• email — character varying (uzunliksiz). string turi uchun TypeORM tanlovi.

Hammasi START TRANSACTION … COMMIT ichida bajarildi (logda ko'rinadi). Bo'sh bazada bu qulay: bir buyruqda jadvallar tayyor.

4. Repository: CRUD

4.1 save va find

Repository (ombor) — bitta entity bilan ishlash uchun metodlar to'plami. 25-qismdagi o'z VazifaOmbori imizga o'xshaydi, faqat tayyor.

const fRepo = ds.getRepository(Foydalanuvchi);
const vRepo = ds.getRepository(Vazifa);

const ali = fRepo.create({
  email: "ali@example.com", toliqIsm: "Ali Valiyev" });
await fRepo.save(ali);
console.log("--- ali.id:", ali.id);

await vRepo.save([
  { matn: "Bozordan non olish", egasi: ali },
  { matn: "Hisobot yozish", egasi: ali, bajarildi: true },
]);

create() faqat obyekt yasaydi (bazaga bormaydi). save() — yozadi va bazadan qaytgan id ni obyektga qo'yadi. Log (bo'lingan):

query: START TRANSACTION
query: INSERT INTO "foydalanuvchilar"("email", "toliq_ism")
  VALUES ($1, $2) RETURNING "id"
  -- PARAMETERS: ["ali@example.com","Ali Valiyev"]
query: COMMIT
--- ali.id: 1

Qiymatlar $1, $2 parametr sifatida ketdi — SQL injection'dan himoya (Parametrli so'rovlar). Ikki vazifa esa bitta INSERT … VALUES (…), (…) bilan yozildi.

save() ning bir nozik joyi bor: obyektda id bo'lsa, TypeORM avval uni SELECT qiladi, keyin INSERT yoki UPDATE ni tanlaydi. Qulay, lekin bitta yozuv uchun ikki so'rov. Aniq maqsad bo'lsa — insert() yoki update().

4.2 find va where

find — obyekt shaklidagi so'rov:

const royxat = await vRepo.find({
  where: { egasi: { id: ali.id }, bajarildi: false },
  order: { id: "ASC" },
  take: 10,
});
console.log(royxat);

Natija:

[
  Vazifa {
    id: 1,
    matn: 'Bozordan non olish',
    bajarildi: false,
    yaratilganVaqt: 2026-10-25T09:28:35.473Z,
    egasi: undefined,
    izohlar: undefined
  }
]

Natija — oddiy obyekt emas, Vazifa klassining nusxasi. egasi: undefined — relation yuklanmagan (so'ralmagan).

Logga qarasak, kutilmagan narsa bor. TypeORM bitta emas, ikkita so'rov yubordi:

-- 1) faqat id'lar, DISTINCT ichki so'rov bilan
SELECT DISTINCT "distinctAlias"."Vazifa_id" AS "ids_Vazifa_id", …
FROM (SELECT … FROM "vazifalar" "Vazifa"
  INNER JOIN "foydalanuvchilar" "Vazifa__Vazifa_egasi" ON …
  WHERE … ) "distinctAlias"
ORDER BY "distinctAlias"."Vazifa_id" ASC, "Vazifa_id" ASC
LIMIT 10
-- 2) shu id'lar bo'yicha to'liq qatorlar
SELECT … FROM "vazifalar" "Vazifa" INNER JOIN …
WHERE ( … ) AND ( "Vazifa"."id" IN (1) )
ORDER BY "Vazifa"."id" ASC

Sabab: where relation orqali (egasi: { id }) — demak JOIN. JOIN + take bo'lganda TypeORM "bitta vazifa bir necha qatorga ko'payib ketmasin" deb ehtiyot bo'ladi: avval noyob id'larni oladi, keyin ularni yuklaydi. Kanon o'lchovida aynan shu sabab TypeORM'ning relation savoli 2 SQL bilan 3.78 ms oldi (pg — 1.34 ms, bitta so'rov).

4.3 Operatorlar, update va delete

Tenglikdan boshqa shartlar — maxsus funksiyalar bilan: Like, ILike, In, IsNull, MoreThan, Between, Not.

import { Like } from "typeorm";
console.log(await vRepo.countBy({ matn: Like("%yozish%") }));
console.log(await vRepo.update(
  { matn: "Hisobot yozish" }, { bajarildi: false }));
console.log(await vRepo.delete({ matn: "Hisobot yozish" }));

Natija:

1
UpdateResult { generatedMaps: [], raw: [], affected: 1 }
DeleteResult { raw: [], affected: 1 }

affected — nechta qator o'zgardi. update() va delete() ga bo'sh shart ({}) berib ko'rmang — hamma qatorga ta'sir qilishi mumkin; UPDATE va DELETE xavfsiz qoidalari bu yerda ham amal qiladi.

Tekshirib ko'ring: vRepo.find({ where: { bajarildi: false }, take: 10 }) (relation shartisiz) ham ikki so'rov yuboradimi?

5. Relation'lar: relations, eager, lazy

5.1 relations — so'raganda yuklash

const f = await fRepo.findOne({
  where: { email: "ali@example.com" },
  relations: { vazifalar: true },
});
console.log(JSON.stringify(f));

Natija:

{"id":1,"email":"ali@example.com","toliqIsm":"Ali Valiyev","vazifalar":[{"id":1,"matn":"Bozordan non olish","bajarildi":false,"yaratilganVaqt":"2026-10-25T09:28:35.473Z"},{"id":2,"matn":"Hisobot yozish","bajarildi":true,"yaratilganVaqt":"2026-10-25T09:28:35.473Z"}]}

TypeORM LEFT JOIN qildi va natijani daraxtga yig'di. Bu yerda ham findOne (= LIMIT 1) + relation — yana ikki so'rov.

5.2 eager: true — doim yuklash

Relation'ga eager: true qo'ysangiz, find uni har safar o'zi yuklaydi. Biz Vazifa.egasi ga qo'yib ko'rdik:

@ManyToOne(() => Foydalanuvchi, (f) => f.vazifalar, {
  nullable: false, onDelete: "CASCADE", eager: true,
})

vRepo.find() natijasi:

[{"id":3,"matn":"Non olish","bajarildi":false,"yaratilganVaqt":"2026-10-25T09:31:51.773Z","egasi":{"id":1,"email":"ali@example.com","toliqIsm":"Ali Valiyev"}}]

So'rovda INNER JOIN "foydalanuvchilar" paydo bo'ldi — biz so'ramagan bo'lsak ham. Endi har vazifalar ro'yxati foydalanuvchini ham tortadi. Ikki xavf:

• Ortiqcha ma'lumot. 1 000 vazifa — 1 000 marta bir xil foydalanuvchi.
• Zanjir. Foydalanuvchi da ham eager relation bo'lsa — u ham tortiladi.

Qiziq tafsilot: o'sha entity bilan vRepo.createQueryBuilder("v").getMany() — egasi siz qaytdi. QueryBuilder eager ni e'tiborsiz qoldiradi. Bir xil entity ikki usulda ikki xil shakl qaytaradi — eski loyihalarda chalkash xatolarning manbai.

5.3 lazy — Promise orqali

Uchinchi variant — lazy relation: xususiyat turi Promise<Foydalanuvchi> qilib yoziladi va unga birinchi murojaatda alohida so'rov ketadi (await vazifa.egasi). Bu biz N+1 muammosi darsida ko'rgan tuzoqning to'g'ridan-to'g'ri yo'li: siklda har vazifa uchun bitta so'rov. Lazy relation'ni biz sinamadik; TypeORM hujjatlari ham uni "eksperimental" deb belgilaydi.

Xulosa jadvali:

6. QueryBuilder

find ning imkoniyati cheklangan: guruhlash, murakkab JOIN, subquery. Shunda QueryBuilder — SQL'ni zanjir metodlar bilan yig'ish. Kysely va Knex'ga o'xshaydi (Kysely va Knex), faqat entity nomlari bilan.

const qb = vRepo.createQueryBuilder("v")
  .leftJoin("v.egasi", "f")
  .select(["v.id", "v.matn", "f.toliqIsm"])
  .where("f.email = :email", { email: "ali@example.com" })
  .andWhere("v.matn ILIKE :q", { q: "%non%" })
  .orderBy("v.id", "DESC");
console.log(qb.getSql());
console.log(JSON.stringify(await qb.getMany()));

getSql() — SQL'ni bazaga yubormasdan ko'rsatadi (bo'lingan):

SELECT "v"."id" AS "v_id", "v"."matn" AS "v_matn",
  "f"."toliq_ism" AS "f_toliq_ism"
FROM "vazifalar" "v"
LEFT JOIN "foydalanuvchilar" "f" ON "f"."id"="v"."egasi_id"
WHERE "f"."email" = $1 AND "v"."matn" ILIKE $2
ORDER BY "v_id" DESC

Natija:

[{"id":1,"matn":"Bozordan non olish","egasi":{"toliqIsm":"Ali Valiyev"}}]

Muhim qoida: :email — nomli parametr, qiymat alohida obyektda. TypeORM uni $1 ga aylantiradi. Lekin .where(\f.email = '${email}'`)deb yozsangiz — bu SQL injection, xuddi$queryRawUnsafe` dagidek (Prisma: raw SQL).

Yana bir kuzatuv: biz select da faqat f.toliqIsm ni so'radik, haqiqiy so'rovda esa "f"."id" AS "f_id" ham qo'shildi. TypeORM obyektni yig'ish uchun birlamchi kalitni o'zi qo'shadi.

7. Migratsiyalar va synchronize xavfi

7.1 synchronize mavjud bazada

Endi bazada ma'lumot bor. Entity'da matn ni sarlavha ga qayta nomladik. synchronize nima qilishini avval faqat ko'rib chiqamiz — createSchemaBuilder().log() (bazaga yozmaydi):

renaming column "matn" in "vazifalar" to "sarlavha"
ALTER TABLE "vazifalar" RENAME COLUMN "matn" TO "sarlavha"

Yaxshi: TypeORM 1.1 bitta ustun nomi o'zgarganini "rename" deb tanidi, ma'lumot qoldi. Endi esa turini o'zgartirdik: @Column({ type: "text" }) → @Column({ length: 50, nullable: true }). Reja:

columns changed in "vazifalar". updating: sarlavha
ALTER TABLE "vazifalar" DROP COLUMN "sarlavha"
ALTER TABLE "vazifalar" ADD "sarlavha" character varying(50)

ALTER COLUMN … TYPE emas — DROP COLUMN + ADD. synchronize: true bilan ishga tushirdik, keyin bazaga qaradik:

 id | sarlavha 
----+----------
  1 | 
(1 row)

"Bozordan non olish" yo'qoldi. Hech qanday ogohlantirish, savol yoki xato yo'q edi.

Birinchi urinishda ustun NOT NULL edi (nullable siz). U holda ADD … NOT NULL mavjud qatorlarda yiqildi (column "sarlavha" of relation "vazifalar" contains null values), tranzaksiya qaytdi va ma'lumot saqlandi. Ya'ni ma'lumotni sizni "omad" saqlaydi, TypeORM emas.

Uch tajribani yonma-yon qo'yamiz:

Diqqat: synchronize: true — faqat o'quv va prototip uchun, tashlab yuboriladigan bazada. Hamkasbingiz bilan bo'lishilgan dev bazada, staging va prodakshnda — hech qachon. TypeORM hujjati ham shuni aytadi.

7.2 migration:generate

To'g'ri yo'l — migratsiya: sxema o'zgarishi alohida faylda, kod bilan birga Git'da. Migratsiya tushunchasini keyingi darslarda chuqur o'rganamiz (Migratsiya tushunchasi); bu yerda TypeORM'ning o'z vositasini ko'ramiz.

CLI uchun DataSource alohida faylda eksport qilinadi (src/data-source.ts):

import { DataSource } from "typeorm";
import { Foydalanuvchi, Vazifa, Izoh } from "./entities.js";

export default new DataSource({
  type: "postgres",
  url: process.env["DATABASE_URL"],
  entities: [Foydalanuvchi, Vazifa, Izoh],
  migrations: ["dist/migrations/*.js"],
  synchronize: false,
});

Bo'sh bazaga qarab migratsiya yasaymiz (avval tsc):

npx tsc -p .
npx typeorm migration:generate -d dist/data-source.js \
  src/migrations/Boshlangich

Migration …\src\migrations/1792920661943-Boshlangich.ts has been generated successfully.

TypeORM entity'lar bilan bazani solishtirdi va farqni SQL'ga aylantirdi. Fayl (qisqartirildi):

export class Boshlangich1792920661943
  implements MigrationInterface {
  name = 'Boshlangich1792920661943'

  public async up(queryRunner: QueryRunner): Promise<void> {
    await queryRunner.query(`CREATE TABLE "foydalanuvchilar" …`);
    await queryRunner.query(`CREATE TABLE "vazifalar" …`);
    // … indeks, izohlar, 2 ta FOREIGN KEY
  }

  public async down(queryRunner: QueryRunner): Promise<void> {
    await queryRunner.query(`ALTER TABLE "izohlar" …`);
    // … teskari tartibda
    await queryRunner.query(`DROP TABLE "foydalanuvchilar"`);
  }
}

up — oldinga, down — orqaga. Nomdagi raqam — Date.now(), migratsiyalar tartibi shundan.

Maslahat: Generatsiya qilingan faylni har doim o'qing. Agar entity o'zgarishi turini o'zgartirish bo'lsa, generate ham synchronize dagi DROP COLUMN + ADD ni yozishi mumkin. Farqi — endi buni review'da ko'rasiz va qo'lda ALTER COLUMN … TYPE … USING ga almashtirasiz.

7.3 run, show, revert

npx typeorm migration:show -d dist/data-source.js
npx typeorm migration:run -d dist/data-source.js
npx typeorm migration:show -d dist/data-source.js

Natija (asosiy qatorlar):

[ ] Boshlangich1792920661943
1 migrations are new migrations must be executed.
query: START TRANSACTION
query: CREATE TABLE "foydalanuvchilar" …
query: INSERT INTO "migrations"("timestamp", "name") VALUES ($1, $2) -- PARAMETERS: [1792920661943,"Boshlangich1792920661943"]
Migration Boshlangich1792920661943 has been executed successfully.
query: COMMIT
[X] 1 Boshlangich1792920661943

TypeORM bazada migrations jadvalini yaratdi va qo'llangan migratsiyani unga yozdi. Bu — holat jadvali: keyingi run qaysilari qo'llanganini shu yerdan biladi. migration:revert oxirgi migratsiyaning down ini bajaradi va yozuvni o'chiradi:

Now reverting it...
query: START TRANSACTION
query: DROP TABLE "izohlar"
query: DROP TABLE "vazifalar"
query: DROP TABLE "foydalanuvchilar"
query: DELETE FROM "migrations" WHERE "timestamp" = $1 AND "name" = $2 -- PARAMETERS: [1792920661943,"Boshlangich1792920661943"]
Migration Boshlangich1792920661943 has been reverted successfully.
query: COMMIT

Yana ikki foydali bayroq (CLI yordamidan, 1.1.2):

• migration:run -t each — har migratsiya alohida tranzaksiyada. Sukut (all) — hammasi bitta tranzaksiyada. CREATE INDEX CONCURRENTLY kerak bo'lsa, migratsiya klassida transaction = false va -t each (yoki migrationsTransactionMode).
• migration:run --fake — migratsiyani bajarmasdan "qo'llandi" deb yozadi. Mavjud bazani migratsiyaga o'tkazishda (baseline) kerak — Prisma Migrate chuqur darsida xuddi shu muammoni ko'ramiz.

Tekshirib ko'ring: migration:revert ni prodakshnda ishga tushirish xavfsizmi?

8. Ko'p uchraydigan xatolar

1. synchronize: true prodakshnda. Yuqorida ko'rdik: tur o'zgarishi — DROP COLUMN. Tuzatish: synchronize: false, faqat migratsiyalar. Muhit o'zgaruvchisiga bog'lab qo'yish ham xavfli (synchronize: NODE_ENV !== "production") — staging'da NODE_ENV noto'g'ri bo'lsa, o'sha zahoti ma'lumot ketadi.

2. column distinctAlias.Vazifa_tartib does not exist. Kanon o'lchovida uchragan: relation + take + order da saralash ustuni select ichida yo'q edi. TypeORM yuqoridagi ikki bosqichli DISTINCT so'rovini yasaydi va tashqi ORDER BY ichki so'rovda yo'q ustunga ishora qiladi. Tarjimasi: "distinctAlias.Vazifa_tartib ustuni mavjud emas". Tuzatish: saralash ustunini select ga qo'shing.

3. Data type "Object" … is not supported. Biz @Column() izoh: string | null; yozib ishga tushirdik:

DataTypeNotSupportedError | Data type "Object" in "Sinov.izoh" is not supported by "postgres" database.

Tarjimasi: "Sinov.izoh dagi Object turini postgres bazasi qo'llamaydi". Birlashma tur (string | null) metama'lumotda Object bo'lib qoladi — TypeORM ustun turini topa olmaydi. Tuzatish: @Column({ type: "text", nullable: true }) — turini aniq yozing.

4. Dekoratorli entity node src/…ts da ishlamaydi. Type stripping dekoratorni bajarmaydi (kanon topilmasi). Tuzatish: tsc bilan kompilyatsiya yoki EntitySchema.

5. save() ni hamma joyda ishlatish. Bitta yangilash uchun SELECT + UPDATE. Ko'p yozuvli ommaviy yangilashda — update() yoki QueryBuilder .update().

6. Cheklov nomlari hash. UQ_56243fb8… xatosini ko'rib "qaysi cheklov?" deb qolasiz. Tuzatish: @Unique("foydalanuvchilar_email_key", ["email"]), @Index("…"), foreignKeyConstraintName — nomni o'zingiz bering.

9. Mashqlar

Mashq yechimlarining SQL qismi tekshirilgan (biz ishga tushirdik, PostgreSQL 17.6).

1-mashq (oson)

Entity'da @Column({ length: 100 }) toliqIsm bor. Siz uni @Column({ length: 150 }) ga o'zgartirdingiz va migration:generate qildingiz. Generatsiya qilingan faylda qanday buyruqni ko'rishni xohlaysiz va qanday buyruq chiqsa, faylni qo'lda tuzatasiz?

2-mashq (o'rta)

Har foydalanuvchining bajarilmagan vazifalari sonini qaytaradigan QueryBuilder yozing (toliqIsm, soni), soni bo'yicha kamayish tartibida, faqat soni > 0 bo'lganlar. Keyin TypeORM yuboradigan SQL'ni o'zingiz yozib, bazada sinang.

Ishora: .select("f.toliqIsm", "toliqIsm"), .addSelect("COUNT(v.id)", "soni"), .groupBy("f.id"), .having(…), natija — .getRawMany() (agregat entity emas, xom qator). Guruhlash — Agregatlar, GROUP BY va HAVING.

const r = await fRepo.createQueryBuilder("f")
  .innerJoin("f.vazifalar", "v", "v.bajarildi = :b",
    { b: false })
  .select("f.toliqIsm", "toliqIsm")
  .addSelect("COUNT(v.id)::int", "soni")
  .groupBy("f.id")
  .having("COUNT(v.id) > 0")
  .orderBy("soni", "DESC")
  .getRawMany();

CREATE TABLE foydalanuvchilar (id serial PRIMARY KEY,
  email varchar NOT NULL UNIQUE,
  toliq_ism varchar(100) NOT NULL);
CREATE TABLE vazifalar (id serial PRIMARY KEY,
  matn text NOT NULL,
  bajarildi boolean NOT NULL DEFAULT false,
  egasi_id int NOT NULL REFERENCES foydalanuvchilar
    ON DELETE CASCADE);
INSERT INTO foydalanuvchilar (email, toliq_ism) VALUES
  ('ali@example.com', 'Ali Valiyev'),
  ('malika@example.com', 'Malika Karimova'),
  ('jasur@example.com', 'Jasur Aliyev');
INSERT INTO vazifalar (matn, bajarildi, egasi_id) VALUES
  ('Non olish', false, 1), ('Hisobot', true, 1),
  ('Kitob', false, 1), ('Sport', false, 2),
  ('Xat', true, 3);
SELECT f.toliq_ism AS "toliqIsm",
  COUNT(v.id)::int AS soni
FROM foydalanuvchilar f
JOIN vazifalar v ON v.egasi_id = f.id AND v.bajarildi = false
GROUP BY f.id
HAVING COUNT(v.id) > 0
ORDER BY soni DESC;

CREATE TABLE
CREATE TABLE
INSERT 0 3
INSERT 0 5
    toliqIsm     | soni 
-----------------+------
 Ali Valiyev     |    2
 Malika Karimova |    1
(2 rows)

3-mashq (qiyin)

vazifalar.matn ga indeks kerak, lekin jadval katta va prodakshnda yozuvlar to'xtamasligi kerak. TypeORM migratsiyasini qo'lda yozing: up — CREATE INDEX CONCURRENTLY, down — DROP INDEX CONCURRENTLY. Nima uchun migratsiyaga qo'shimcha sozlama kerak va qaysi?

import { MigrationInterface, QueryRunner } from "typeorm";

export class MatnIndeksi1792921000000
  implements MigrationInterface {
  name = "MatnIndeksi1792921000000";
  // CONCURRENTLY tranzaksiya ichida ishlamaydi
  transaction = false;

  public async up(q: QueryRunner): Promise<void> {
    await q.query(`CREATE INDEX CONCURRENTLY IF NOT EXISTS
      vazifalar_matn_idx ON vazifalar (matn)`);
  }

  public async down(q: QueryRunner): Promise<void> {
    await q.query(
      `DROP INDEX CONCURRENTLY IF EXISTS vazifalar_matn_idx`);
  }
}

10. Loyiha qadami

Bu dars vazifalar-api ga kod qo'shmaydi. Kanon qarori o'lchovga tayanadi: API'da Prisma asosiy, pg — taqqoslash va xom SQL uchun. TypeORM — eski loyihalarda uchraydi, yangi loyihaga tavsiya etilmaydi.

Kanon TypeORM'ni o'sha katta bazada (500 000 vazifa, egasi 77, mediana 30) boshqa kutubxonalar bilan bir xil savollarda o'lchagan:

TypeORM eng sekin chiqdi (ikki so'rov sababli) — lekin farq millisekundlarda. Paket hajmi esa sezilarli: TypeORM 28 MB, pg 179 KB. Tanlovni hal qiladigan narsa — tezlik emas, xavfsizlik va qulaylik. Buni ORM tanlash qo'llanmasi da jamlaymiz.

O'zingiz sinamoqchi bo'lsangiz — alohida tajriba papkasida (vazifalar-api ga emas): npm i typeorm@1.1.2 pg@8.23.1, bo'sh baza, synchronize: true faqat birinchi ishga tushirishda. Commit yo'q.

11. Real ishda

• NestJS loyihalari. @nestjs/typeorm orqali TypeOrmModule.forFeature([Vazifa]), @InjectRepository(Vazifa). NestJS'ni 30-qismda o'rganamiz; u yerda ham shu entity va repository tushunchalari ishlaydi.
• Kod review. Eski TypeORM loyihasiga kelsangiz, birinchi tekshiradigan narsa: synchronize qayerda yoqilgan? Ikkinchisi: eager: true lar qayerda?
• Active Record uslubi. Ba'zi loyihalarda entity BaseEntity dan meros oladi va Vazifa.find() kabi statik metodlar ishlatiladi. Biz ko'rgan uslub — Data Mapper (repository orqali); ikkalasini ham o'qiy olasiz.
• Intervyuda: "synchronize nima va nega xavfli?", "eager va lazy farqi?", "QueryBuilder qachon kerak?" — javobda DROP COLUMN tajribasini va N+1 ni tilga oling.

Xulosa

• TypeORM — dekoratorli entity'lar (@Entity, @Column, @ManyToOne), legacy dekoratorlar va emitDecoratorMetadata kerak; Node type stripping ularni bajarmaydi.
• DataSource — ulanish va sozlama; Repository — find, save, update, delete; QueryBuilder — murakkab so'rovlar, nomli parametrlar bilan.
• Relation + take — ikki so'rovli DISTINCT naqsh; kanon o'lchovida 3.78 ms (pg 1.34 ms).
• eager doim yuklaydi (QueryBuilder'dan tashqari), lazy — N+1 yo'li; asosiy usul — relations.
• synchronize: true tur o'zgarishida DROP COLUMN + ADD qildi va ma'lumot yo'qoldi — prodakshnda faqat migratsiya.
• migration:generate → faylni o'qing → migration:run; holat migrations jadvalida; sukut — hamma migratsiya bitta tranzaksiyada.

Keyingi dars: Sequelize — eski Express loyihalarining ORM'i: Model.init, associations, include, Op va sequelize-cli migratsiyalari.

Manbalar

• TypeORM hujjati — Entities, Relations, Eager and Lazy Relations, Migrations: https://typeorm.io/docs/
• TypeORM 1.1.2 paket kodi: MigrationInterface.transaction, migration:run --transaction, --fake (2026-10-25 holati).
• NestJS hujjati — Database (TypeORM integratsiyasi): https://docs.nestjs.com/techniques/database
• IlmHamroh kanon o'lchovi t29-orm (PostgreSQL 18.6, 2026-10-25); darsdagi TypeORM chiqishlari — biz ishga tushirdik (TypeORM 1.1.2, PostgreSQL 17.6, Windows 11), 2026-10-25.