partage des uuid exemples

[gildeluermoz]

Lors de transferts de données entre la LPO et les réserves naturelles régionales du Drac (instance GeoNature que je gère), Julien Girard-Claudon de la LPO Auvergne Rhône Alpes me fait remarquer que la fourniture de l'uuid d'un cadre d'acquisition fait doublon avec un uuid déjà utilisé par une autre structure. En cause la réutilisation du cadre d'acquisition exemple fourni à l'installation de GeoNature. On peut voir son usage ici : https://github.com/PnX-SI/GeoNature/search?q=57b7d0f2-4183-4b7b-8f08-6e105d476dc5

Vigilance donc lors du partage de données si des jdd ou des CA exemples ont été modifiés en vrais JDD ou CA. D'autant qu'il n'est pas possible pour le moment de supprimer un CA exemple via l'interface : https://github.com/PnX-SI/GeoNature/issues/1673 A réfléchir pour résoudre ce souci. Peut-petre faire un update à la fin de l'insertion des données exemples pour que la base propage la modification de l'UUID - voir SQL ci-dessous pour un des CA.

En attendant il est prudent de mettre à jour ses uuid si vous partagez des données ou si vous remontez au SINP: Voici le sql que j'ai passé pour corriger le pb :

UPDATE gn_meta.t_acquisition_frameworks 
SET unique_acquisition_framework_id = uuid_generate_v4()
WHERE unique_acquisition_framework_id = '57b7d0f2-4183-4b7b-8f08-6e105d476dc5';

Merci Julien. Bien vu :+1:

[bouttier]

Les données d’exemple pourrait être inséré avec un UUID aléatoire, mais dans ce cas, on ne serait pas en mesure de savoir lesquelles supprimé lorsque l’on descend la branche Alembic associé. Une solution pourrait être de ne pas utiliser une branche Alembic, mais une commande d’insertion des données d’exemple, ne nécessitant pas de prévoir une suppression des données (l’utilisateur se débrouille). Il devient alors plus un soucis d’utiliser des UUID aléatoires, et en plus, le contexte de la commande permet d’utiliser les modèles SQLAlchemy. Ça nous éviterait des soucis lors d’évolutions de la base de données comme ça a pu être le cas avec les données d’exemple d’OccTax il y a pas si longtemps.

[camillemonchicourt]

Surtout pour des instances de production, il ne faudrait pas insérer les données d'exemple. C'est pour des instances de test mais pas de production.

Je suggère déjà de désactiver par défaut l'insertion des données d'exemple, pour que ça soit un choix de l'administrateur.

[gildeluermoz]

Une solution pourrait être de ne pas utiliser une branche Alembic, mais une commande d’insertion des données d’exemple, ne nécessitant pas de prévoir une suppression des données (l’utilisateur se débrouille). Il devient alors plus un soucis d’utiliser des UUID aléatoires

Ca me semble pas mal. Je pense que très peu d'administrateurs utilisent les commandes Alembic pour downgrade l'insertion des exemples.

Surtout pour des instances de production, il ne faudrait pas insérer les données d'exemple. C'est pour des instances de test mais pas de production.

Les données exemples permettent aussi d'avoir une instance immédiatement utilisable. Même si limitée, ça permet de faire qq premiers tests immédiatement après install pour vérifier que tout est en place et fonctionnel.

Je suggère déjà de désactiver par défaut l'insertion des données d'exemple, pour que ça soit un choix de l'administrateur.

oui, dans ce sens c'est mieux.

[pguillermin]

J'ai le même soucis avec les exports INPN après avoir réutilisé le JDD fourni comme exemple "contact aléatoire tous règnes confondus" 4d331cae-65e4-4948-b0b2-a11bc5bb46c2. Le gestionnaire de données a déjà cet UUID en base associé à un autre CA. Il faut donc que je recalcule les UUID exemples dans ma base locale.

[camillemonchicourt]

Oui, on n'est pas censé se baser et utiliser en production ces JDD et CA d'exemple :-) Il vaut mieux les supprimer ou ne pas intégrer les données d'exemple pour une instance de production.

On pourrait tout à fait regénérer ces UUID, voir même ne pas les fournir lors de l'installation pour que la BDD les génère aléatoirement à chaque installation. Mais comme mentionner plus haut, on utilise ces UUID pour les tests automatiques, pour associer les JDD d'exemple aux CA d'exemple, mais aussi pour pouvoir downgrader la branche Alembic contenant les données de test : https://github.com/search?q=repo%3APnX-SI%2FGeoNature%204d331cae-65e4-4948-b0b2-a11bc5bb46c2&type=code

[DonovanMaillard]

Oui, on n'est pas censé se baser et utiliser en production ces JDD et CA d'exemple :-)

Le soucis c'est qu'on ne peut pas supprimer un CA depuis l'interface, donc c'est bien plus simple de renommer et recycler ce CA lors de la mise en place d'une instance.