Англійська для розробників Drizzle ORM

Drizzle ORM став популярним вибором для команд TypeScript, які хочуть SQL-подібний синтаксис запиту з повною безпекою типів і без кроку генерації коду. Якщо ви працюєте з Drizzle у команді сервера, вам знадобиться чітка англійська мова для опису проектування схеми, потоків робіт з перенесення і швидкості виконання запитів під час перегляду коду і під час перевірки. Цей словник допоможе вам чітко спілкуватися, незалежно від того, спілкуєтеся ви з іншим інженером або пишете опис запиту на звантаження.

Ключовий словник

** Визначення схеми ** — файл TypeScript, у якому ви декларуєте таблиці, стовпчики і зв’ язки за допомогою функцій pgTable, mysqlTable або sqliteTable програми Drizzle. Схема є єдиним джерелом правди як для структури бази даних, так і для виведених типів.

• “Додамо новий стовпчик status до визначення схеми перед тим, як ми записаємо міграцію.” *

** Виведення типів ** — можливість Drizzle автоматично виводити типи TypeScript для результатів запиту з вашої схеми, без окремого кроку створення коду. “Однією з причин, чому ми перейшли від Prisma, було виведення типів у Drizzle — воно оновлюється миттєво, коли змінюється схема, без жодного кроку генерації.”

** Migration ** — файл SQL з версіями, зазвичай створений за допомогою drizzle-kit generate, який містить інформацію про відмінності між вашою схемою і поточним станом бази даних.

• “Спочатку запустити міграцію локально, а потім перевірити сформований SQL перед застосуванням його до перевірки.” *

** Конструктор запитів ** — API Drizzle ( db.select(), .from(), .where() ), який відображає сирий синтаксис SQL, залишаючись повністю типованим.

• « Я віддаю перевагу конструктору запитів перед сирим SQL, оскільки він виявляє помилки друку у назвах стовпчиків під час компіляції. » *

** Підготований запит ** — попередньо скомпільований запит, створений за допомогою .prepare(), який можна виконувати декілька разів з різними параметрами для поліпшення швидкодії.

• “Ми перетворили пошук по звичайному шляху на підготовлений запит, який значно скоротив затримку запиту.” *

Relational queries — API db.query Drizzle, який дозволяє отримувати вкладені відносини, подібно до API include ORM, при цьому повертаючи повністю типізовані результати.

• “Використовуйте API реляційних запитів замість ручних з’ єднань, якщо вам просто потрібно долучити автора до кожної статті.” *

** Drizzle Kit ** — інструмент CLI, який використовується для створення міграцій, перенесення змін схеми безпосередньо до бази даних і відкриття Drizzle Studio для перегляду даних. “Запустити drizzle-kit push під час розробки, але ніколи у виробничому режимі — ми завжди хочемо, щоб там були переглядні файли міграції.”

** Zero- runtime overhead ** — фраза, яка описує філософію розробки Drizzle: він компілює до рівня близького до сирого SQL з мінімальними шарами абстракції між вашим кодом і базою даних. “Drizzle продає себе на нульовому часі виконання, тому запит, який ви пишете, є фактично запитом, який виконується.”

Звичайні фрази

• Чи ви регенерували міграцію після зміни схеми?
• «The types didn’t update — are you sure you saved the schema file?» (англійською)
• «Давайте використаємо db.transaction(), щоб обгорнути обидва запису, щоб вони залишилися атомарними»
• «Цей ланцюг будівничого запитів стає важко читати; чи можемо ми витягнути його в помічника?»
• «Підштовхнути схему до бази даних dev спочатку, а потім генерувати реальну міграцію для перегляду.»
• «Перевірте, чи реляція визначена з relations() — інакше API запиту не побачить її»

Приклади висловлювань

При поясненні функції Drizzle нетехнічним користувачам: “Drizzle — це інструмент, який дозволяє нашим інженерам писати код бази даних тією ж мовою, що й інші компоненти програми, що зменшує кількість помилок і прискорює розробку, оскільки помилки виявляються негайно, а не під час виконання.”

Під час створення квитка підтримки:

• “Після оновлення drizzle-kit до останньої версії, наш крок створення міграції зазнав невдачі з невідповідністю типів у стовпчиках enum. Кроки для відтворення долучені, разом з нашим файлом схеми.”*

Під час обговорення архітектури на груповій нараді:

• “Я пропоную зберігати визначення схем у спільному пакунку, щоб і служба API, і фоновий процесор імпортували ті ж самі типи і ніколи не виходили з синхронізації.” *

Професійні поради

• Скажімо “push” проти “generate” навмисно — drizzle-kit push для швидкої локальної ітерації, в той час як generate плюс зафіксований файл міграції є безпечним шляхом для будь-чого, що торкається спільних середовищ.
• Під час перегляду PR, запитайте, чи використовує новий запит ** конструктор запитів ** або ** реляційні запити ** API, оскільки неоднорідне змішування обох стилів у коді ускладнює перегляд.
• Описуйте проблеми виведення типів точно: скажіть « виведений тип не відповідає формі виконання », а не нечітко « типи неправильні » — це вказує переглядачів прямо на схему.
• Використовувати ** підготовлений запит ** спеціально для швидкісних, повторюваних запитів; використання цього терміну для кожного запиту перебільшує те, що насправді відбувається.

Практичні вправи

1. Друг з команди запитує, чому команда відійшла від традиційного ORM з кроком генерації часу збирання. Напишіть два- три речення, що пояснюють переваги виведення типів у Drizzle.
2. Напишіть опис PR у одному реченні, пояснюючи, що ви додали нову міграцію для таблиці subscriptions з зовнішнім ключем users.
3. Поясніть в одному реченні різницю між використанням drizzle-kit push і drizzle-kit generate для молодшого розробника.

Національний склад населення: Комунікаційні проблеми

Будьмо чесними - професійна англійська не тільки про знання окремих слів. Це про те, як ви їх використовуєте, особливо при обговоренні технічних деталей, таких як Drizzle ORM. Багато не-рідних розробників знаходять швидке темп комунікації в командах розробників, особливо під час перегляду коду або планування спринту, приголомшливим. Незначні відмінності у фразуваннях можуть призвести до непорозумінь і розчарування. Здається простим запит на «рефактор» може бути інтерпретований по-іншому, ніж було заплановано, що призведе до марних зусиль. Аналогічно, пояснення логіки за складним дизайном конструктора запитів вимагає точності, яка часто відсутня, коли покладатися виключно на прямий переклад.

Одна з найчастіших проблем виникає при обговоренні потенційних вузлів продуктивності. Замість того, щоб просто сказати «цей запит повільний», що може звучати обвинувачуючим, набагато ефективніше - і професійніше - конструктивно висловлювати свою занепокоєність. Фрази на кшталт «Цей запит може отримати користь від оптимізації» або «Дослідимо, чи можемо ми поліпшити ефективність цього запиту» набагато краще приймаються. Крім того, розуміння різниці між пропозиціями і вимогами є критичним. Переглядач коду може запропонувати пропозицію щодо поліпшення («Чи можемо ми використовувати індекс тут?»), У той час як власник продукту може вказати вимогу («Ми повинні переконатися, що цей звіт запускається протягом 5 секунд»). Неправильне тлумачення цих відмінностей може повністю зірвати прогрес. Нарешті, не бійтеся ставити прояснюючі питання - такі фрази, як “Чи можете ви розібратися, що ви маєте на увазі під …?” або “Чи можете ви дати мені приклад очікуваної поведінки?” демонструють активний підхід і мінімізують неоднозначність.

Ключовим є прийняти менталитет, зосереджений на ясному, точному спілкуванні, а не на прагненні до буквальної точності. Сфокусування на * намір * і використання добре встановлених шаблонів фраз значно поліпшить ваші взаємодії в команді. Пам’ ятайте, що документація, навіть неформальні повідомлення Slack, повинні бути написані з чітким розумінням — припускаючи, що хтось незнайомий з проектом читає її.

Ось приклад опису дії з перенесення за допомогою програми Drizzle:

-- Create a new table named 'users' with id as primary key and name as string.
CREATE TABLE users (
  id INTEGER PRIMARY KEY,
  name TEXT NOT NULL
);

Цю просту команду, якщо обговорювати її з колегою, можна було б сформулювати більш формально і точніше: « Я створив міграцію для введення таблиці users з цілим первинним ключем ( id ) і текстовим стовпчиком, який не можна скасувати, для зберігання імен користувачів ». Зауважте, що у цьому випадку уникається надмірно неформальної мови, на зразок « створити таблицю », і використовується більш описова термінологія. Це про передачу * саме * те, що команда робить, в такий спосіб, що легко зрозуміти будь-кому, хто знайомий з синтаксисом визначення схеми Drizzle.