> Какие вопросы возникают при работе с миграциями в Prisma (JavaScript)

Короткий ответ

При работе с миграциями в Prisma возникают вопросы управления схемой БД, синхронизации с продакшеном, обработки конфликтов в команде, rollback-ов, seed-данных и shadow database. Для senior-уровня важно понимать trade-off между prisma migrate dev и prisma db push, стратегии ветвления миграций, работу с кастомными SQL-миграциями и решение проблем с дрейфом схемы.

Подробное объяснение

Prisma Migrate генерирует SQL-файлы миграций на основе изменений в schema.prisma. Ключевые проблемы:

1. Дрейф схемы (schema drift) - когда состояние БД расходится с файлами миграций. Возникает при ручных правках БД или параллельных ветках. Решается через prisma migrate resolve или prisma db push для синхронизации.

2. Конфликты в команде - несколько разработчиков меняют схему одновременно. Нужна стратегия: либо линейная история миграций (rebase), либо изолированные ветки с последующим мержем.

3. Rollback миграций - Prisma не поддерживает автоматический откат. Приходится писать кастомные down-миграции или использовать prisma migrate diff для генерации обратных изменений.

4. Shadow database - временная БД для проверки миграций. Проблемы: права доступа, конфликты имен, производительность при больших схемах.

5. Seed-данные - интеграция с prisma seed требует настройки и может конфликтовать с миграциями при пересоздании таблиц.

6. Production миграции - применение prisma migrate deploy в CI/CD требует блокировок, обработки ошибок и мониторинга длительных операций.

На практике

Для senior-разработчика критично:

• Использовать prisma migrate dev только локально, для CI/CD - prisma migrate deploy с проверкой baseline
• Хранить миграции в репозитории и никогда не редактировать уже примененные файлы
• При дрейфе схемы: сначала prisma migrate diff для анализа, затем prisma migrate resolve с флагом --rolled-back или --applied
• Для сложных изменений (переименование колонок, изменение типов) писать кастомные SQL-миграции вручную
• Настраивать prisma generate после каждой миграции в пайплайне
• Использовать prisma db push только для прототипирования, не для продакшена

Пример кода

JAVASCRIPT
// Кастомная миграция для безопасного переименования колонки
// migrations/20240101_rename_column/migration.sql

-- 1. Создаем новую колонку
ALTER TABLE "User" ADD COLUMN "fullName" TEXT;

-- 2. Копируем данные
UPDATE "User" SET "fullName" = "name";

-- 3. Удаляем старую колонку
ALTER TABLE "User" DROP COLUMN "name";

// В schema.prisma:
model User {
  id       Int    @id @default(autoincrement())
  fullName String
}

JAVASCRIPT
// Seed-файл с проверкой состояния
import { PrismaClient } from '@prisma/client';

const prisma = new PrismaClient();

async function main() {
  // Проверяем, не был ли seed уже выполнен
  const existing = await prisma.user.findFirst();
  if (existing) {
    console.log('Seed already applied, skipping');
    return;
  }

  await prisma.user.createMany({
    data: [
      { fullName: 'Alice' },
      { fullName: 'Bob' },
    ],
  });
}

main()
  .catch(console.error)
  .finally(() => prisma.$disconnect());

Как отвечать на собеседовании

Начни с ключевых проблем: дрейф схемы, конфликты, rollback. Покажи понимание разницы между migrate dev и deploy. Приведи реальный кейс из практики: например, как решал конфликт миграций в команде из 5 разработчиков. Упомяни shadow database и её настройку. Для senior-уровня важно показать, что ты не просто используешь Prisma, а понимаешь внутренние механизмы и можешь проектировать процесс миграций под конкретный проект.

Что проверяет интервьюер

• Понимание жизненного цикла миграций в Prisma
• Умение решать проблемы дрейфа и конфликтов
• Знание best practices для production окружений
• Способность проектировать процесс миграций в команде
• Понимание trade-off между автоматическими и ручными миграциями
• Опыт работы с кастомными SQL и seed-данными

Типичные ошибки

• Путают migrate dev и migrate deploy - первый для разработки, второй для CI/CD
• Редактируют уже примененные миграции вместо создания новых
• Не используют shadow database в production-подобных окружениях
• Забывают про prisma generate после миграций
• Пытаются делать rollback через удаление файлов миграций
• Игнорируют seed-данные при пересоздании таблиц
• Не проверяют миграции на копии production БД перед деплоем