Certaines applications publiées plus anciennes peuvent encore être connectées à une base de données de développement qui a été créée à l’origine pour une application différente. Cela peut arriver avec des applications plus anciennes qui ont été forkées ou remixées sur Replit. Avec l’ancienne configuration Neon, un fork pouvait continuer à utiliser la connexion à la base de données de l’application d’origine. Dans le cadre du passage de Replit à l’isolation complète des bases de données de développement et de production, les anciennes bases de données de développement partagées sont supprimées et les applications publiées doivent migrer vers leurs propres bases de données de production. Utilisez ce guide si votre application publiée affiche des erreurs de connexion à la base de données, ou siDocumentation Index
Fetch the complete documentation index at: https://docs.replit.com/llms.txt
Use this file to discover all available pages before exploring further.
DATABASE_URL dans le panneau Secrets pointe toujours vers neon.tech.
Avant de commencer
Votre application publiée a besoin de sa propre base de données de production. La base de données de développement affichée dans le panneau Database ne doit pas être utilisée directement par les applications publiées.
- Cas 1 : Les données souhaitées sont déjà présentes dans la base de données affichée dans le panneau Database de votre application.
- Cas 2 : Le panneau Database n’affiche pas les données dont vous avez besoin, car votre application publiée utilise encore l’ancienne base de données de développement partagée.
Comment savoir si votre application publiée utilise une base de données partagée ?
Votre application publiée est concernée si l’une des conditions suivantes est vraie :- Votre application publiée affiche des erreurs de connexion à la base de données après la mise à niveau de la base de données
- Votre application a été remixée depuis une autre application qui avait une base de données avant le 9 janvier 2026
Comment vérifier si votre application publiée utilise la base de données partagée de l’application source ?
Étape 1 : Ouvrez le panneau Database dans l’application source
NEON_DATABASE_URL ou depuis DATABASE_URL si NEON_DATABASE_URL n’existe pas.
Toutes les applications concernées n’auront pas forcément
NEON_DATABASE_URL. Si elle est absente, cela
signifie généralement que vous devez utiliser le DATABASE_URL actuel depuis les Secrets de
l’application publiée s’il pointe toujours vers neon.tech.Étape 2 : Ouvrez le panneau Publish dans l’application publiée
- Ouvrez votre application dans Replit
- Ouvrez le panneau Publishing
- Ouvrez Adjust Settings
- Ouvrez Secrets
- Recherchez
DATABASE_URL
Étape 3 : Comparez l’URL de la base de données de l’application source à l’étape 1 et de l’application remixée à l’étape 2
Si elles sont identiques, votre application publiée utilise une base de données de développement Neon partagée depuis l’application source.Comment copier les données de l’application source vers l’application publiée ?
Après avoir confirmé que votre application publiée utilise la base de données de développement partagée de l’application source, l’étape suivante consiste à transférer les données nécessaires vers l’application publiée. Deux scénarios sont à considérer :- Cas 1 : Le panneau Database de l’application publiée contient déjà les données requises.
- Cas 2 : Le panneau Database de l’application publiée ne contient pas les données requises.
Cas 1 : Le panneau Database affiche déjà les données dont vous avez besoin
C’est le chemin le plus simple si les données dont vous avez besoin sont déjà visibles dans le panneau Database de votre application.Étape 1 : Confirmez que les données sont présentes
Étape 2 : Publiez ou republiez avec une base de données de production
- Ouvrez votre application dans l’éditeur de projet
- Sélectionnez Publish ou Republish
- Activez Create production database
- Activez Set up your production database with your current development data
- Finalisez le flux de publication
DATABASE_URL sur la nouvelle base de données de production. Vous n’avez pas besoin de mettre à jour ce secret manuellement pendant ce flux.
Étape 3 : Vérifiez l’application publiée
Ouvrez votre application publiée et confirmez que vos données sont accessibles et que l’application fonctionne correctement.Cas 2 : Le panneau Database de l’application publiée n’affiche pas les données dont vous avez besoin
Suivez ces étapes pour exporter les données si vous ne voyez pas les données nécessaires dans le panneau Database de votre application publiée. Si votre application publiée est encore connectée à une base de données d’une autre application, vous verrez un avertissement « external database detected » dans le panneau Database.
Étape 1 : Exportez les données depuis l’ancienne base de données
database_url est l’URL de la base de données obtenue à l’Étape 1 : Ouvrez le panneau Database dans l’application source.
Étape 2 : Supprimez l’ancien DATABASE_URL des Secrets de votre application
- Ouvrez l’outil Secrets dans l’éditeur de projet
- Trouvez l’ancien
DATABASE_URL - Supprimez-le
- Actualisez la page ou rouvrez le panneau Database
Étape 3 : Importez les données dans la base de données de développement actuelle de votre application
DATABASE_URL ancien supprimé, la base de données de développement actuelle de votre application devrait être à nouveau disponible en tant que $DATABASE_URL dans l’éditeur de projet.
Retournez au Shell dans l’éditeur de projet et exécutez :
Étape 5 : Suivez le Cas 1 pour publier ou republier avec une base de données de production
Une fois que le panneau Database affiche les données correctes, suivez le Cas 1 pour publier ou republier avec Create production database et copier ces données en production.Étape 6 : Vérifiez l’application publiée
Résolution des problèmes
L’import échoue parce que les tables existent déjà
La commandepg_restore --clean --if-exists ci-dessus supprime et recrée les objets correspondants du dump avant de les restaurer.
L’import échoue avec des erreurs de rôle ou de politique
Si votre base de données utilise des rôles PostgreSQL personnalisés ou des politiques basées sur des rôles, l’import peut échouer parce que ces rôles n’existent pas encore dans la nouvelle base de données. La migration automatique Helium de Replit tente de recréer des stubs de rôles avant la restauration, mais le processus manuel ci-dessus ne le fait pas. Si vous rencontrez des erreurs liées aux rôles lors depg_restore, contactez le support pour obtenir de l’aide.