> > Et pourquoi mettre à jour un système qui donne satisfaction ?
>
> Bugs corrigés, soucis de sécurité, etc. :)
Bien sûr. Il se trouve qu’aucun ne s’est manifesté à ce jour en ce qui nous
concerne.
Cela veut dire que le code marche bien. ( <- un peu une basse flatterie mais je n’ai
pas pu resister. Mais c’est vrai: 0 problème avec garradin/paheko depuis plusieurs
années… Ce n’est pas le cas avec la plupart des logiciels dit commerciaux. Merci pour
cela. )
;-)
>
> > 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.
Je comprends les contraintes de temps et de ressources.
Pas de problème.
>
> > 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 :)
Ok. Je vais faire cela.
Je préfère quand il y a une doc, mais encore une fois, je comprends les contraintes de
ressources et de temps.
>
> > 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 :)
Exact. Pour un membre, c’est négligeable.
Mais l’expérience me fait savoir que tout morceau de code à succès commence toujours
pas des compromis qui font mal dans le futur.
>
> > 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.
Très bonne idée: je n’y avais même pas pensé.
Mais ok, je vais lire le code.
C’est l’avantage des codes open source.
:D
>
> > 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.
Encore une fois, bonne idée. Merci du conseil. Je ne l’avais pas envisagé.
Ma réticence à lire le code…
:D
> > 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.
>
Je suis une personne plutôt RTFM et c’est pour cela que j’ai toujours une réticence
à aller lire le code.
Mais encore une fois, je comprends les contraintes de temps.
Merci d’avoir déjà pris le temps de “critiquer” mon approche: cela m’a déjà
donner deux directions à explorer.
> Bonne soirée :)
Suite au prochain numéro, je pense.