Chemin de mise à niveau Prisma MongoDB
Les projets MongoDB sont la seule cohorte Prisma sans chemin vers Prisma 7 : la v6 est la version majeure terminale de l'ORM classique pour MongoDB, et la v7 n'expédie jamais de connecteur MongoDB. Le chemin successeur est Prisma Next, où le support MongoDB est en Early Access avec une disponibilité générale (GA) prévue après PostgreSQL. Cette compétence présente la véritable décision — migrer vers Prisma Next (le chemin encouragé) ou rester sur la v6 lorsqu'un blocage dur s'applique — et fournit les mécanismes de migration.
Ne faites jamais l'une de ces choses :
- Ne conseillez jamais à un projet MongoDB de « passer à Prisma 7 ». Le connecteur n'existe pas là-bas. Le guide
prisma-upgrade-v7ne s'applique pas aux projets MongoDB. - Ne résolvez jamais la question de version en réécrivant l'application sur une base de données SQL. Changer le moteur de base de données est une décision séparée et bien plus vaste qui ne vous appartient pas de prendre implicitement.
Le paysage des versions
| Version | Statut MongoDB |
|---|---|
| Prisma ORM v6 | Entièrement pris en charge (fournisseur mongodb) ; la dernière 6.x est le chemin stable actuel ; ligne de maintenance |
| Prisma ORM v7 | Aucun connecteur MongoDB — pas une option, jamais |
| Prisma Next | Support MongoDB en Early Access, activement développé, GA prévue après PostgreSQL — le chemin successeur pour les projets MongoDB |
La décision, dès le départ
Migrer vers Prisma Next est le chemin encouragé. Le support MongoDB dans Prisma Next est en Early Access : fonctionnel et évolue rapidement, avec une GA prévue après PostgreSQL — et l'équipe Prisma souhaite que les utilisateurs MongoDB migrent tôt et partagent leurs retours. Les mécanismes de migration sont détaillés dans les références.
Rester sur la dernière v6 reste un choix légitime lorsqu'un blocage dur s'applique — dit clairement : la façade Next Mongo n'encapsule pas encore les transactions (le pilote sous-jacent est disponible directement ; cela devrait changer bientôt), et les versions mineures pré-1.0 peuvent comporter des changements cassants avec des recettes de mise à niveau publiées.
Tableau de décision
| Signal | Direction |
|---|---|
| Aucun des blocages ci-dessous ne s'applique | Migrer vers Next ; exécuter la verify-cutover-checklist et partager les retours avec l'équipe Prisma |
| Greenfield / prototype / outil interne | Migrer vers Next |
Le codebase utilise des transactions multi-documents ($transaction) — vérifier avec grep, ne pas demander | Planifier d'abord les équivalents session via le pilote brut (voir client-api-mapping), ou rester sur v6 jusqu'à ce que l'encapsulation par la façade soit disponible |
| L'équipe ne peut pas absorber les mises à niveau cassantes pré-1.0 entre mineurs | Rester sur v6 jusqu'à la GA |
| Aversion au risque mais intéressé | Exécuter un aller-retour intermédiaire avec Next sur une copie (voir verify-cutover-checklist), puis migrer |
Remarque : l'écart de transactions devrait se combler bientôt — cette section sera mise à jour lorsque les transactions par façade seront fusionnées dans Prisma Next.
Si vous restez sur v6 : hygiène (un maintien délibéré, pas une négligence)
- Épingler les paquets Prisma à la dernière ligne 6.x et continuer à prendre les correctifs 6.x.
- Suivre les notes de version Prisma et les avis de sécurité pour la ligne 6.x.
- Conserver la configuration classique v6 MongoDB :
url = env("DATABASE_URL")dans le schéma, workflowdb push, pas d'adaptateurs de pilote SQL (voirprisma-database-setuppour la forme v6 MongoDB). - Réévaluer lorsque MongoDB de Prisma Next sera en GA, ou lorsque les blocages pour essayer l'EA seront résolus.
Fichiers de référence
| Référence | Ce qu'elle couvre |
|---|---|
references/decision-stay-or-migrate.md | Le cadrage complet de la décision, les vérifications de blocage et les détails d'hygiène de maintien |
references/schema-contract-mapping.md | Schéma v6 (fournisseur mongodb, @db.ObjectId, types composites) → concepts de contrat Next |
references/client-api-mapping.md | Appels client v6 → équivalents Next, y compris les échappatoires brutes et les transactions — les noms correspondent, la parité n'est pas |
references/migrations-mapping.md | Histoire v6 uniquement db push → flux planifier/migrer/vérifier/signer de Next |
references/verify-cutover-checklist.md | Vérification sans déplacement de données : même DB, parité des index, aller-retour intermédiaire avant basculement |
Vérifié par rapport à
Les affirmations comportementales concernant Prisma Next dans cette compétence ont été vérifiées par rapport à
prisma/prisma-next au commit
a2791c5dd59d579b4b3052942ae7f8fe5e2ee852 (pré-1.0, ligne ~v0.14/0.15). Prisma Next évolue rapidement en Early Access : avant d'agir sur une quelconque affirmation relative à Next, vérifiez-la par rapport à la version réellement installée (vérifiez les versions @prisma-next/* du projet et les compétences prisma-next installées avec). La cible Mongo de Next nécessite MongoDB 8.0+ et attend mongodb@^7 comme dépendance homologue fournie par l'utilisateur.
Règle de passage de relais
Cette compétence est le pont de découverte, pas un remplacement de la propre documentation de Prisma Next. Après qu'un projet soit passé à Prisma Next, exécutez les commandes init/d'installation de compétences de Prisma Next et suivez ses propres compétences (démarrage rapide, contrat, requêtes, migrations, exécution) pour le travail quotidien — ne continuez pas à travailler à partir des résumés de cette compétence.