Copying Data from production to non-production

Request description

Bonjour, nous voudrions faire une copie de nos tables de nos environnements de production vers nos environnements de tester pour faire des tests plus aboutis, pour faire cette opération qu’elles sont les tables que nous ne devons pas copier pour ne pas perdre nos configurations de tests, mais juste les données ?

Merci ,

Technical information

Instance /health
[Platform]
Status=OK
Version=5.3.3
BuiltOn=2023-05-15 21:17
Git=5.3/176d083640b1853d16f2bd5eee90829bdcbd8702
Encoding=UTF-8
EndpointIP=172.17.0.4
EndpointURL=http://9a22eb9a171e:8080
TimeZone=Europe/Paris
SystemDate=2023-07-18 14:57:39

[Database]
Vendor=3
ProductName=PostgreSQL
ProductVersion=14.7
DriverName=PostgreSQL JDBC Driver
DriverVersion=42.6.0
DBDate=2023-07-18 14:57:39
DBDateOffset=0
DBPatchLevel=5;P03;41863ccff4986c2930d9a9e7758aabab
UsingBLOBs=true

Faire des export/imports partiels des tables de la base de données n’est pas forcément une bonne approche.

Vos données métier sont dans les tables que vous avez configurées, les autres tables sont les tables du méta-modèle Simplicité qui contient votre paramétrage.

L’exception (= la table qui est à cheval sur les deux monde) c’est la table m_document qui contient potentiellement des documents du méta modèlme (ex: des sources, des resources, …) mais aussi des documents métier.

Et plus généralement les row ID risquent toujours de poser des pbs tordus sur des imports partiels niveau physique.

Les bonnes approches sont donc plutôt:

  1. Exporter votre paramétrage de dev (= tous vos modules), puis remplacer la base de dev par un dump de prod complet, puis réimporter le paramétrage exporté (en prime cette approche vous permet de tester le processus d’upgrade de votre instance de prod y compris les éventuelles reprises de données)

  2. Exporter les données via des mécanismes au niveau logique : export ZIP, XML ou, mieux, paramétrage et export d’un dataset, puis les importer sur votre instance de dev (après avoir fait le ménage de données métier précédentes). Cette approche, en particulier la dernière, n’est pas forcément techniquement viable si vous avez de très gros volumes de données métier.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.