Topic

Notes API — Postgres + TypeORM milestone

Definition

Milestone P2 proves Notes persist in PostgreSQL with TypeORM entities, a reviewed migration, a seeder, and a User↔Note relation with synchronize left false.

In simpler words

Understand how Notes persist with TypeORM entities, migrations, and seeds.

Maps to Week 2 SQL + TypeORM. Use W3Schools SQL/PostgreSQL under /resources if you need query refreshers.

Open official example (opens in new tab)

After this you can

Add Note + User entities and a migration with FKs/indexes
Keep synchronize: false in runtime and CLI DataSource
Seed users/notes safely and load authors without N+1 on list

What this stage covers

Definition

This stage is a Notes API build slice: read the official Nest chapter, understand the matching Nest concepts, then take the quiz to lock it in.

In simpler words

Score ≥80% on the quiz below to save roadmap progress — exactly like every other topic.

Official docs: Nest TypeORM technique — https://docs.nestjs.com/techniques/database

Key Nest pieces to understand: entities, migrations, the CLI DataSource (data-source.ts), and a seed script

Supplemental tutorials: /resources → W3Schools SQL + PostgreSQL

Optional practice: rebuild the same slice for Notes in your own workspace to cement the pattern.

What a correct build includes

- [ ] synchronize: false in AppModule + data-source
- [ ] Migration reviewed; entities listed
- [ ] Seed creates users + notes

Use this as the acceptance checklist while you study the concepts and answer the quiz.

Deliverables

Definition

Deliverables are the concrete Nest files and behaviors a correct version of this stage produces.

In simpler words

Aim for the smallest vertical slice that satisfies these — not a sprawling redesign.

Note entity with author ManyToOne User

Migration creating tables/FKs; seed at least two users and notes

List uses join/relation load for author

Keep in mind

Never turn synchronize true “just for practice”.
Read generated SQL before migration:run.

Test

Check your understanding

At least 10 questions — mix of concept, syntax, practical, and logic. Score ≥80% (enforced by the API) to save progress.

Checking your session…

15 questions · concept 5 · syntax 3 · practical 4 · logic 3

1. What does Notes P2 require?

Concept

TypeORM entities with synchronize true so migrations are unnecessaryEntities and a migration but no User↔Note relation yetA reviewed migration plus seed data stored only in localStorageTypeORM entities, a reviewed migration, seed data, User↔Note relation, synchronize false

2. How do you prove P2?

Syntax

pnpm course:validate-milestone be-notes-p2 before running any migrationspnpm migration:run alone, since the grader only checks the schemapnpm course:validate-milestone be-notes-p2 after migrations and seed existpnpm course:validate-milestone be-notes-p1 now that persistence exists

3. Why synchronize false?

Practical

Schema changes go through reviewed migrationsIt makes TypeORM read the schema from migrations at every startupIt stops TypeORM from validating entities against the databaseIt defers all schema changes to seed scripts instead of migrations

4. What should seed data do?

Logic

Run the migrations first, then insert baseline rows in the same fileInsert baseline notes/users safely for demos without breaking re-runsTruncate all tables before inserting so demos always start cleanAdd the author foreign key column and then populate it

5. Why a User↔Note relation?

Concept

A join table lets any note be shared across all users equallyNotes need an author/owner foreign key for real persistence craftThe relation lets TypeORM auto-generate the CreateNoteDtoRelations enable synchronize true to manage the schema safely

6. What if a migration was already applied incorrectly?

Practical

Edit the applied migration file and re-run it against the databaseRevert the whole migrations table and regenerate from entitiesFlip synchronize true once to reconcile the drift, then off againAdd a new forward migration — do not casually rewrite applied history

7. Can P2 be proven without notes-practice code?

Syntax

No — the grader expects real persistence artifacts in the practice appYes — a single migration file satisfies the grader without entitiesYes — describing the schema in PLATFORM.md is sufficientYes — running seed.ts against an in-memory Map proves persistence

8. What does the grader look for conceptually?

Logic

Entities with synchronize true and a passing seed scriptMigrations plus JwtAuthGuard protecting the notes routessynchronize false, migrations, seed, and author relation loadingA pagination { data, meta } contract on the list endpoint

9. Should notes live only in web localStorage for P2?

Concept

No — persist with TypeORM/Postgres in notes-practiceYes — localStorage mirrors the Postgres rows for offline demosYes — the browser store is the source of truth until P4 adds a DBYes — TypeORM only starts persisting after the P3 auth milestone

10. Which P2 shortcut is wrong?

Practical

Writing a reviewed migration for each schema changeSeeding baseline rows with an idempotent scriptModeling the author foreign key with @ManyToOneTurning synchronize true so schema changes never need migrations

11. What does this contribute to P2?

Conceptintermediate

@Entity('notes')
export class Note {
  @PrimaryGeneratedColumn('uuid')
  id: string;
  @Column()
  title: string;
}

Generates and applies the notes migration automaticallyMaps the Note entity to a notes table for TypeORM persistenceCreates the notes table on startup because of the @Entity decoratorDefines the CreateNoteDto used by the controller

12. Why is synchronize:false required for P2?

Syntaxadvanced

TypeOrmModule.forRoot({ url, synchronize: false });

It forces TypeORM to load the schema from migration files at bootIt prevents entities from being registered with forFeatureIt makes the seed script responsible for creating tablesSchema changes must go through reviewed migrations, not auto-sync

13. What does this add for P2?

Practicalintermediate

@ManyToOne(() => User)
@JoinColumn({ name: 'author_id' })
author: User;

A one-to-many where each user embeds all their notes inlineA bidirectional relation that also adds notes[] on User automaticallyA many-to-many join table between users and notesA User-to-Note relation via an author foreign key

14. Why check findOneBy before saving in the seed?

Logicadvanced

const existing = await repo.findOneBy({ email });
if (!existing) await repo.save(user);

To keep the seed idempotent so re-runs do not duplicate rowsTo upsert the row by merging changed fields on each runTo lock the row so concurrent seeds cannot both insertTo load the author relation before saving the note

15. Where does this DDL belong?

Conceptintermediate

await q.query('ALTER TABLE notes ADD COLUMN author_id uuid');

In a reviewed migration, not the seed scriptIn the entity file as a @Column so TypeORM applies itIn a repository method that runs it once on module initIn the seed script, right after the baseline rows are inserted

Checking your session…