Simplifier la prise en charge de données dans un store samba

[CharlesGaydon]

          > Pourquoi il y a besoin de gérer l'utilisation d'un store samba dans ce code ? Est-ce qu'on ne peut pas juste supposer que l'utilisateur l'aura monté comme un dossier sur sa machine ou est-ce que ça offre des avantages particuliers ?

Ici la principale motivation c'est que dans LiPaC ce sont les chemins absolus dans le store qui sont stockés et utilisés pour faire référence aux nuages de point. Il n'y a pas de notion de montage. Je souhaitais éviter des opérations de conversion relou.

Mais je conviens que c'est lourd... Dans tous les cas il faut gérer le décalage quelque part :

1. soit on supporte le store samba dans pacasam comme maintenant, et on doit préciser des identifiants quand les fichiers sont dans un store.
2. soit il faut faire la traduction, p.ex. de \\store.ign.fr\store-LIDARHD\XX\\YY\ZZ.laz vers /mnt/store-lidarhd/XX/YY/ZZ.laz. Cette conversion se ferait dans le connecteur LiPaC. Puisque comme son nom l'indique c'est un connecteur spécifique à la base de données... Soit en python, soit en SQL (mais ça semble plus galère qu'autre chose, quoique ?)
3. Soit on envisage une nouvelle colonne dans LiPaC directement avec une version "le chemin si le store était monté sous /mnt/". C'est simple à faire, mais ça fait de l'info redondante.

L'option 2 paraît pas déconnante en fait... J'y reréfléchis demain mais ça permet de virer toutes les réf à smbprotool ça simplifie les choses. Et puis on a une façon assez standard de monter le store, dans /mnt/, donc ça ne demande pas trop de travail à priori.

Pour l'historique, c'est Michel qui a commencé à utiliser cet outil car a) il ne voulait pas être dépendant d'un mount, et 2) les droits de lecture dans un mount étaient galère à gérer avec postgreSQL.

Originally posted by @CharlesGaydon in https://github.com/IGNF/pacasam/issues/24#issuecomment-1607831703

Ok je comprends mieux ! J'élimierais l'option 3 d'office parce qu'on n'aura jamais tous la même convention (ce qui est déjà le cas) Dans d'autres outils, on a pris le parti de faire la conversion à la volée (à partir d'un paramètre donné en entrée du script) masi ce n'est pas focrément la meilleure solution. Ca peut être un truc à chercher dans des futures améliorations mais je penses que ça ne vaut pas forcément le coup de tout changer dans cette MR

Originally posted by @leavauchier in https://github.com/IGNF/pacasam/pull/24

--> Simplification du code à considérer.

[CharlesGaydon]

L'option 2 n'est pas adéquate : on veut que l'échantillonnage ne soit pas dépendant d'un montage spécifique, donc la conversion ne peut se faire qu'à l'extraction, pas dans le connecteur.

[CharlesGaydon]

Je reviens sur ce point. Il s'agit d'un outil spécifiquement conçu pour Lipac, dans un environnement spécifique IGN. On peut tout à fait envisager une conversion de \store.ign.fr\store-LIDARHD\XX\YY\ZZ.laz vers /mnt/store-lidarhd/XX/YY/ZZ.laz. Et on n'a ainsi plus besoin d'identifiants SAMBA, et pacasam fonctionnera sans autre changement au niveau de l'utilisation.

[CharlesGaydon]

Décision -> convention /mnt/... à documenter.

[leavauchier]

C'est une convention dans la base ou dans le code avec une conversion des infos de la base finalement ?

[CharlesGaydon]

Convention dans le code :)