| Les deux révisions précédentes Révision précédente Prochaine révision | Révision précédente |
| database:import-formats [2024/10/23 14:38] – [À faire / Améliorations] jpmilcent | database:import-formats [2025/01/03 08:14] (Version actuelle) – ancienne révision (2024/12/20 10:14) restaurée choarau |
|---|
| ==== Notes diverses ==== | ==== Notes diverses ==== |
| * Les champs contenant des dates au format ''[DATE(YYYY-MM-DD HH:MM:SS)]'' peuvent éventuellement contenir aussi les microsecondes séparées des secondes par un point. Ex. : ''2019-03-07 12:09:14.451907''. C'est le cas pour les champs ''meta_create_date'' et ''meta_update_date''. L'ajout de cette information peut servir à indiquer la nécessité de mise à jour d'un enregistrement en cas de modification très rapprochées réalisées par un outil automatique par exemple. La plupart du temps, cette information est inutile et alourdit le fichier CSV. | * Les champs contenant des dates au format ''[DATE(YYYY-MM-DD HH:MM:SS)]'' peuvent éventuellement contenir aussi les microsecondes séparées des secondes par un point. Ex. : ''2019-03-07 12:09:14.451907''. C'est le cas pour les champs ''meta_create_date'' et ''meta_update_date''. L'ajout de cette information peut servir à indiquer la nécessité de mise à jour d'un enregistrement en cas de modification très rapprochées réalisées par un outil automatique par exemple. La plupart du temps, cette information est inutile et alourdit le fichier CSV. |
| * Les champs de type UUID, INT, JSON ou DATE ne devrait pas contenir de valeur vide mais la chaine indiquant l'utilisation de la valeur NULL (''\N''). Si les fichiers transmis contiennent des valeurs vides pour les champs de ces types, elle sera transformé en NULL par le parser (script Python) lors de l'intégration. | * Les champs de type UUID, INT, JSON ou DATE ne devrait pas contenir de valeur vide mais la chaine indiquant l'utilisation de la valeur NULL (''\N''). Si les fichiers transmis contiennent des valeurs vides pour les champs de ces types, elle sera transformé en NULL par le parser (script Python) lors de l'intégration. Pour les champs ''meta_create_date'' et ''meta_update_date'', ça prendra la valeur par défaut ''now()'' (date d'import en base GN). |
| |
| ==== Champs additionnels ==== | ==== Champs additionnels ==== |
| |
| ==== À faire / Améliorations ==== | ==== À faire / Améliorations ==== |
| | * <todo>Trouer une solution au problème du remplacement des caractères \n, \r… qui ne fonctionne pas lors de l'import dans la base</todo> |
| * <todo>Modifier le nom du champ //determiner// de la ressource //SYNTHESE// en //determiner**s**//</todo> | * <todo>Modifier le nom du champ //determiner// de la ressource //SYNTHESE// en //determiner**s**//</todo> |
| * <todo>Intégrer si nécessaire les nouveaux champs de GeoNature v2.6.0 aux formats (-- @jpmilcent 2021-02-21) :</todo> | * <todo>Intégrer si nécessaire les nouveaux champs de GeoNature v2.6.0 aux formats (-- @jpmilcent 2021-02-21) :</todo> |
| * <todo>Revoir le format des champs "cor_actors_organism" et "cor_actors_user" du format ACQUISITION_FRAMEWORK. La récupération des valeurs de tableaux imbriqués nécessite de passer par du JSON (idem pour les champs de type ARRAY du DATASET). Il serait donc plus efficace d'utiliser directement le format JSON pour ces champs.-- @jpmilcent 2021-02-21.</todo> | * <todo>Revoir le format des champs "cor_actors_organism" et "cor_actors_user" du format ACQUISITION_FRAMEWORK. La récupération des valeurs de tableaux imbriqués nécessite de passer par du JSON (idem pour les champs de type ARRAY du DATASET). Il serait donc plus efficace d'utiliser directement le format JSON pour ces champs.-- @jpmilcent 2021-02-21.</todo> |
| * <todo #jpmilcent:2024-10-23>Dans le format DATASET, indiquer les valeurs par défaut des nomenclatures à utiliser. Les champs correspondant dans la table GeoNature étant obligatoire ! Les nomenclatures ne sont pas obligatoires pour les cadres d'acquisition et la synthese.</todo> | * <todo #jpmilcent:2024-10-23>Dans le format DATASET, indiquer les valeurs par défaut des nomenclatures à utiliser. Les champs correspondant dans la table GeoNature étant obligatoire ! Les nomenclatures ne sont pas obligatoires pour les cadres d'acquisition et la synthese.</todo> |
| * <todo>Pour le format USER, trouver un solution pour éviter les doublons d'email et d'identifiant => se baser sur l'email => trouver une solution pour la mise à jour de l'email => ajouter un champ "new_email" + champ "email" (= ancien email) + "meta_last_action" = "U".</todo> => ajout d'index unique à la base de données. | * <todo #jpmilcent:2024-10-23>Pour le format USER, trouver un solution pour éviter les doublons d'email et d'identifiant => se baser sur l'email => trouver une solution pour la mise à jour de l'email => ajouter un champ "new_email" + champ "email" (= ancien email) + "meta_last_action" = "U".</todo> => ajout d'index unique à la base de données. |
| * <todo #jpmilcent:2024-10-23>Pour le format ORGANISM, trouver une solution pour éviter les doublon inter-fournisseur => se baser sur l'UUID du [[http://standards-sinp.mnhn.fr/referentiel-des-organismes/|référentiel national SINP des organismes]].</todo> | * <todo #jpmilcent:2024-10-23>Pour le format ORGANISM, trouver une solution pour éviter les doublon inter-fournisseur => se baser sur l'UUID du [[http://standards-sinp.mnhn.fr/referentiel-des-organismes/|référentiel national SINP des organismes]].</todo> |
| * <todo #jpmilcent:2024-10-23>Pour les formats ACQUISITION_FRAMEWORK et DATASET, trouver une solution pour éviter les doublon inter-fournisseur => se baser sur le site "[[https://inpn.mnhn.fr/docs-web/docs/download/263010|Référentiel National SINP - Métadonnées]]". </todo> | * <todo #jpmilcent:2024-10-23>Pour les formats ACQUISITION_FRAMEWORK et DATASET, trouver une solution pour éviter les doublon inter-fournisseur => se baser sur le site "[[https://inpn.mnhn.fr/docs-web/docs/download/263010|Référentiel National SINP - Métadonnées]]". </todo> |
jpmilcent