> Hello,
Salut,
>
> Visiblement tu n'avais pas mis à jour depuis plusieurs années car ce
> changement est vieux :)
En effet, je ne suis pas fana des mises à jour automatique: cela casse plus de chose
(La mise à jour à d’ailleurs cassé mon intégration qui marchait parfaitement
avant…)
Et pourquoi mettre à jour un système qui donne satisfaction ?
>
> La collation "exotique" permet de trouver "Émilie" quand tu
cherche
> "emilie" dans les membres, donc c'est plutôt utile :)
Je comprends l’intérêt de la collation exotique mais sa présence empêche également
l’utllisation de tout outil tiers.
Le rapport coût/bénéfice ne m’apparaît donc pas comme évident.
Il aurait été également possible de l’implémenter dans la fonction de recherche.
C’est un poil plus complexe et peut-être un peu moins efficace. A voir…
>
> Dans la version 1.3 il y aura une seconde table où les noms des membres
> sont déjà transformés, sans accents, et en minuscules, pour éviter
> l'usage de cette collation oui.
En l’espèce, je ne vois pas comment cela facilitera mon intégration.
Au contraire, cela m’obligera à faire deux entrées dans deux tables différentes en
maintenant une cohérence.
>
>
> MAIS de toutes façons c'est pas une super idée d'aller bidouiller
la
> base de données à la main,
Dans le principe c’est vrai.
Mais juste ajouter une ligne dans une table avec de la donnée “morte” me semble peu
risqué.
D’ailleurs, quelles sont les règles à respecter si l’on crée une ligne dans la
table membres ?
Y a-t-il des infos à maintenir en cohérence dans d’autres tables ?
> je te conseille plutôt d'utiliser l'API :
> https://paheko.cloud/api
>
> Notamment tu peux utiliser la route /user/import
L’API REST est pratique lorsque l’on fait une intégration “externe” à base de
curl ou wget.
Et on gagne effectivement les contrôles d’intégrité de la base via l’application.
Mais elle rajoute plutôt de l’overhead quand on écrit des scripts PHP hebergés sur le
même serveur.
Et elle limite les fonctionnalités disponibles.
Dans mon cas d’emploi, une API sous forme de scripts PHP serait plus adéquate.
>
> Exemple :
>
> echo 'numero,nom' > membres.csv
> echo '42,"Nouveau nom"' >> membres.csv
> curl https://test:abcd@monpaheko.tld/api/user/import -T membres.csv
Oui, pour une intégration externe, c’est parfait.
Mais dans le cas d’un script PHP, il faut:
1/ créer un fichier depuis le script PHP
2/ faire un appel externe à un process
3/ nettoyer le filesystem.
Tout cela est très lourd (dans mon cas d’emploi).
Et je suis pas sûr d’être autorisé à faire un appel process externe chez mon
hébergeur.
Alors qu’on a la requête “INSERT …” directement depuis l’API sqlite.
En fait, en read-only, l’API a peu d’intérêt (dans mon cas d’emploi) car on
dispose de toute l’API sqlite.
>
> Si tu modifie directement la base de données, il y a de fortes chances
> que tu ne fasse pas les choses correctement et que ça casse des trucs
> dans Paheko, d'où l'intérêt d'utiliser l'API :)
Oui, c’est le seul avantage.
Encore une fois, le rapport coût/bénéfice n’est pas évident car je veux juste créer
un enregistrement avec des informations “terminale”.
>
> S'il te manque des choses dans l'API, ne pas hésiter à me signaler
;)
Merci !
Et merci de ta réponse et de ton temps.
PYL
PS: Je pense que retirer la collation et implémenter une fonction de recherche est plus
indiqué: cela permet d’utiliser n’importe quel outil tiers ce qui a beaucoup de
valeur pour les intégrateurs.
> Et pourquoi mettre à jour un système qui donne satisfaction ?
Bugs corrigés, soucis de sécurité, etc. :)
> Il aurait été également possible de l’implémenter dans la fonction de
> recherche. C’est un poil plus complexe et peut-être un peu moins
> efficace. A voir…
C'est ce qui était fait avant, mais tu imagine bien que si j'ai changé
c'est qu'il y a une raison :)
En effet les perfs avec 5000+ membres étaient trop mauvaises. La
fonction empêche d'utiliser les index, alors que la collation peut être
indexée elle (à condition d'être déterministe).
Comme je l'ai dit ça va changer dans la 1.3.0, justement parce que un
des objectifs de Paheko est le BDD soit le plus lisible possible sans
bidouilles, à des fins de conservation.
Maintenant, passer de la collation au système actuel, c'est plusieurs
semaines de boulot à temps plein, tu imagine bien que ça ne se fait pas
dans un claquement de doigts. Et du coup la "meilleure" solution (ou la
moins pire, selon le point de vue) c'est de doublonner la table users
pour avoir une seconde table indexée, ça évite d'avoir à créer des
index avec la collation (d'où ton erreur à l'insertion : il faut la
collation pour pouvoir créer l'index). Ça oblige à devoir gérer deux
tables.
> D’ailleurs, quelles sont les règles à respecter si l’on crée une
> ligne dans la table membres ?
>
> Y a-t-il des infos à maintenir en cohérence dans d’autres tables ?
Le code est dispo, je te laisse le lire :)
> Mais elle rajoute plutôt de l’overhead quand on écrit des scripts PHP
> hebergés sur le même serveur.
Oui enfin c'est que dalle sur l'ajout de quelques membres, faut être
sérieux à un moment :)
> Et elle limite les fonctionnalités disponibles.
>
> Dans mon cas d’emploi, une API sous forme de scripts PHP serait plus
> adéquate.
Et bien tu n'as qu'à utiliser l'API en PHP directement en appelant le
code en direct.
> Mais dans le cas d’un script PHP, il faut:
>
> 1/ créer un fichier depuis le script PHP
> 2/ faire un appel externe à un process
> 3/ nettoyer le filesystem.
Heu non pas besoin de créer un fichier ni de faire un appel externe, tu
peux juste utiliser file_get_contents, ou la libcurl. C'était juste un
exemple.
> Oui, c’est le seul avantage.
> Encore une fois, le rapport coût/bénéfice n’est pas évident car je
> veux juste créer un enregistrement avec des informations “terminale”.
Pour toi si tu veux, mais tu pense bien que je n'ai ni le temps, et
encore moins l'énergie de répondre à ce genre de mails et expliquer
toute l'API interne de Paheko à tout le monde. Je préfère consacrer mon
temps à être utile aux 6000+ assos qui font du Paheko "classique". Tu
as toujours accès à tout : la BDD, le code, l'API interne ou l'API
publique, selon ce que tu veux faire, mais je ne vais pas écrire tes
requêtes à ta place, je te laisse lire le code et faire ce que tu veux
:)
Comme je l'ai dit, la seule méthode recommandée est d'utiliser l'API,
si tu veux aller bidouiller à la main, tu peux, mais tu te débrouille,
je n'ai pas le temps / l'énergie d'aller aider chaque personne qui ne
veut pas utiliser ce qui est conçu pour une interaction externe.
Bonne soirée :)