Disgression et forum de destination - Page 1

Quand un utilisateur demande une disgression dans un topic, que je sache le nouveau topic est dans le meme sous forum, ce n'est pas forcement le plus aproprie, ca serait peut etre une bonne idee de proposer les sous forums du forum courant

Pour être sur, pour moi

sous forum == "Questions et suggestions"
forum == "Le site"

dans le cas courant.

Je suis d'accord, et même avec ce changement la fonction digression reste pas idéale puisqu'on perd le début de la discussion. Idéalement j'aimerais avoir quelque chose à mi-chemin entre le fork et la digression, qui pourrait être rendu accessible à tout le monde au lieu d'être limité aux modérateurs. La seule raison pour laquelle le fork est limité aux modérateurs actuellement c'est parce que rien n'empêche de faire des forks sur 500 messages et dupliquer trop de contenu sur yN (ce qui pourrait avoir des conséquences sur la taille de la base, la qualité du référencement, etc.). Je pense qu'il faudrait mieux trouver quelque chose qui n'implique pas de dupliquer du contenu mais jusqu'ici je n'ai pas trouvé de solution satisfaisante. Mettre une limite arbitraire à "N messages max" ne fait que décaler le problème, et un système dans lequel un même message pourrait simultanément appartenir à plusieurs sujets risque d'être à la fois complexe à implémenter et complexe à comprendre pour les lecteurs.

Toutes les suggestions sont les bienvenues pour améliorer tout ça (et ça tombe bien, on est dans la bonne section !)

Ah d'ailleurs pour le vocabulaire c'est tout expliqué ici TL;DR : Forum > Section > Sujet > Message

Zeph (./2) :
Mettre une limite arbitraire à "N messages max" ne fait que décaler le problème

Sur le papier oui, mais en pratique ça me semble à la fois efficace, simple à mettre en œuvre et pas gênant pour les utilisateurs normaux. Si tu limites à (au pif) 50 messages maximum, et au moins 12 heures entre deux utilisations de la feature par un même utilisateur, ça limite fortement l'impact d'une utilisation malveillante ou d'une boulette.

Mouais, je suis quand même pas convaincu par une limite infranchissable, il y aura forcément un moment où le fork mériterait d'être fait sur plus de 50 messages et où cette limitation semblera arbitraire. À l'inverse, dupliquer 50 messages c'est déjà beaucoup et j'aimerais trouver un moyen d'éviter d'avoir à le faire si possible.

50 est énorme quand même on a rarement plus de 20 sur un fork non?

Et si le fork était validé par un admin/modo/boo?

Un utilisateur qui abuse == ban ou autre truc méchant

Si c'est validé par un modérateur ça n'est pas tellement plus pratique que la solution actuelle : il faudra toujours un modérateur disponible et impossible de réaliser le fork avant ça, je pense que quitte à rendre la fonctionnalité plus accessible autant le faire complètement, mais pas sous sa forme actuelle.

Au passage je la trouve déjà pourrie comme elle est la fonction fork, le seul truc qui la sauve actuellement c'est qu'elle est utilisée de façon anecdotique, mais c'est précisément ça que j'aimerais renverser. Favoriser les forks permettrait à mon avis de s'y retrouver un peu mieux dans les sujets, en incitant les membres à dériver vers une discussion séparée quand c'est utile (= quand on sent qu'il y a à la fois des gens intéressés par le nouveau sujet et des gens qui voudraient continuer l'ancien). Pour l'instant j'ai l'impression qu'on ne le fait pas parce que créer un nouveau sujet implique de perdre les participants de la discussion d'origine (d'où la fonctionnalité digression où Boo signale l'existence du nouveau sujet, mais c'est pas super pratique vu qu'on perd quand même l'historique).

J'imagine qu'il est impossible, au niveau de la structure de données, d'avoir en début de topic non pas une copie de posts mais des références à des posts (qui, visuellement, apparaîtraient comme des posts normaux avec éventuellement une indication, mais qui, du coup, ne prendraient pas beaucoup de place en base) ?
Du coup, côté utilisateur, ça reviendrai à créer un nouveau topic, avec n messages de référence venant d'un topic ailleurs sur yN (avec tout de même des contraintes pour les forums privés, par exemple).

C'est un gros changement mais qui reste envisageable, en revanche je pensais exactement à ce genre de solution à la fin du premier paragraphe de ./2 : j'ai peur que ça soit confus, à moins de trouver une façon d'indiquer visuellement que les messages sont seulement des références. Mais on peut certainement trouver une solution, ça n'est pas le problème ne plus gênant. Les autres auxquels je pense sont :

- Ça provoque une duplication de potentiellement pas mal de contenu, ce qui implique parait-il une pénalité de référencement (je n'ai jamais mesuré si c'était vrai ni dans quelle mesure)
- C'est techniquement jouable si un sujet commence par référencer N messages contigus, mais si on veut faire référence aux messages 5, 8, 11, et 12 du sujet d'à côté ça risque d'être assez crade à représenter (j'ai moyennement envie d'introduire une table de références juste pour cette fonctionnalité, avec le coût supplémentaire que ça va avoir pour rapatrier tous les messages à afficher en une seule requête, à supposer que ce soit encore possible)
- Tout plein de questions de cohérence apparaissent : si le sujet d'origine devient privé, que deviennent les références ? Idem s'il est supprimé ?

Par rapport à tes questionnements :
- Je ne le savais pas (cela dit, vu la quantité d'information présente sur yN, je ne suis pas sûr que ça joue, d'autant que le contenu est déjà dupliqué pour les traductions des sites, non ?
- Hm, oui, je comprends le souci (j'imagine que créer une vue pour ça ne répondrait pas à ton exigence ?)
- Ca, je suis d'accord que c'est un vrai problème, pour lequel il faut avoir une politique définie assez tôt pour tous les cas de figure (mais dans ma vision des choses, la référence réagit en fonction de l'original : s'il devient privé ou s'il est supprimé (ainsi que si les contenus des messages sont édités dans le topic initial), on ne peut plus les lire. Du coup, il faut non seulement informer le lecteur quand il tombe sur une référence comme quoi le message originel est dans un autre topic, mais aussi indiquer dans le topic initial qu'un message est une référence vers une digression (ça permet en plus de s'y rendre tout de suite si besoin, mais aussi pour l'auteur du message de faire attention en l'éditant).

Enfin, ce n'est pas trivial, c'est clair...

Y'a bien une solution qui élimine certains problèmes : tu introduis une balise spéciale, par exemple [refpost=numéro du post d'origine] qui a les effets suivants :
- ça affiche le contenu du post d'origine référencé
- ça affiche un signe distinctif indiquant qu'il s'agit d'un post provenant d'un autre topic (fond coloré différemment, icône particulière...)
- ça désactive la fonction d'édition pour ce post (ou ça redirige vers celle du post d'origine)

Lors du fork / de la digression, tu crées un post dans le nouveau topic pour chaque post d'origine, qui ne contient que la balise spéciale qui référence le post d'origine.

Gros avantage :
- ça ne modifie pas fondamentalement les principes de fonctionnement, et ça consomme peu d'espace en BDD.

Inconvénients :
- ça demande une requête pour chaque post "spécial", donc ça va ramer. Mais vu qu'il y a un cache, ça ne devrait le faire que lors du premier affichage de la page (par contre la gestion du cache devient un peu subtile : l'utilisateur peut avoir ou non les droits d'accès en lecture au topic d'origine, il y a donc deux rendus possibles pour la même page. Il faut aussi invalider le cache si le topic d'origine passe de public à privé ou inversement.)

- contrairement à de la simple copie ou du copy-on-write, on ne peut pas modifier un post à un endroit sans qu'il soit modifié partout ; et si le topic d'origine devient privé, les posts disparaissent partout. Mais c'est pas forcément plus mal, le contraire est complexe à gérer et risque d'embrouiller les gens.

Sur certains sites de news, en scrollant vers la fin de l'article ça passe à l'article suivant de manière fluide, comme si les articles étaient contigus sur la même page.
Or, si on fait attention, on se rend compte que l'url change de manière transparente*.

Ça pourrait être une piste pour la digression : les nouveaux posts seraient sous la nouvelle URL, les anciens qui sont plus haut seraient sur l'ancienne URL.

En pratique, la digression actuelle resterait inchangée, simplement, en scrollant vers le haut ça afficherait les posts du topic d'origine qui précèdent la digression. Éventuellement, les posts de l'ancien topic pourraient apparaître avec une couleur de fond légèrement différente pour garder un repère visuel qu'il s'agit des posts d'un autre topic, mais je ne sais pas si c'est vraiment nécessaire. Ils pourraient aussi être en lecture seule sur la digression.

Ceci, est une révolution.


* je n'ai pas d'exemple sous la main, mais je peux en trouver si vous voulez. cf ./13

(j'ai édité)

Par exemple, ouvrez cette page et srollez vers le bas, ça passe aux articles suivants :
http://madame.legorafi.fr/2016/10/24/5-armes-blanches-quand-on-se-balade-tard-dans-lassemblee-nationale/

Futura-Sciences fait ça aussi.

Oui, et yN aussi

Nil (./9) :
Je ne le savais pas (cela dit, vu la quantité d'information présente sur yN, je ne suis pas sûr que ça joue, d'autant que le contenu est déjà dupliqué pour les traductions des sites, non ?

Oui, mais dans ce cas je sais à coup sûr qu'une page A n'est qu'une vue identique d'une autre page B dans une autre langue, et il y a une balise meta (canonical) qui permettent d'indiquer ça. En fait c'est ce qui permet de ne rien dupliquer malgré la fonctionnalité qui consiste à inclure une section "étrangère" dans un forum (par exemple "J'ai rien à dire" dans le forum Ti), ce qui provoque une URL différente mais je peux indiquer une forme canonique pour préciser que c'est un doublon. Pour les langues c'est un peu différent mais l'idée reste la même. Pas sûr que ce soit simple à reproduire dans le cas des forks, pour lesquels on a seulement des parties de pages recopiées. Mais peut-être aussi qu'en fait on s'en fout

Nil (./9) :
Hm, oui, je comprends le souci (j'imagine que créer une vue pour ça ne répondrait pas à ton exigence ?)

Il faut que je re-vérifie, mais je crois que le MySQL du serveur de yN est une version préhistorique qui ne supporte pas les vues

Nil (./9) :
Ca, je suis d'accord que c'est un vrai problème [...]

Bon, il va falloir que je relise ta réponse à tête reposée

Zerosquare (./10) :
Y'a bien une solution qui élimine certains problèmes : tu introduis une balise spéciale, par exemple [refpost=numéro du post d'origine]

Ça risque d'être catastrophique en termes de performance : comme tu le dis ça fait une requête SQL de plus à chaque rendu de cette balise, et il n'y a aucun cache pour ça (le rendu est supposé être précalculé et très peu couteux à faire). Introduire une fonctionnalité comme celle-ci demanderait non seulement d'avoir un cache par post ou par page de yN (horriblement couteux vu que ça s'ajoute à la cardinalité "skin * langue" déjà existante aujourd'hui, ou alors c'est un tout nouveau cache orthogonal à celui existant, mais ça commence à ressembler à une belle usine à gaz). En plus comme tu l'indiques, ça rendrait les invalidations bien plus complexes qu'elles ne le sont aujourd'hui.

Pen^2 (./11) :
Ça pourrait être une piste pour la digression : les nouveaux posts seraient sous la nouvelle URL, les anciens qui sont plus haut seraient sur l'ancienne URL.

Ah je ne connaissais pas, je regarde ça demain, a priori je trouve dommage que ça soit une fonctionnalité "JS obligatoire" mais peut-être qu'il y a moyen de proposer une version dégradée

Effectivement, sur le gorafi ça ne fonctionne pas sans javascript. J'imagine qu'ils n'ont rien inventé et que le comportement est exactement le même ailleurs.
À la rigueur sans javascript ça pourrait rester identique au fonctionnement actuel, peut-être juste avec un lien vers le topic d'origine ?

Zeph (./16) :
il n'y a aucun cache pour ça (le rendu est supposé être précalculé et très peu couteux à faire). Introduire une fonctionnalité comme celle-ci demanderait non seulement d'avoir un cache par post ou par page de yN (horriblement couteux vu que ça s'ajoute à la cardinalité "skin * langue" déjà existante aujourd'hui, ou alors c'est un tout nouveau cache orthogonal à celui existant, mais ça commence à ressembler à une belle usine à gaz).

Ah OK, je ne pensais pas que ça fonctionnait comme ça.

Ouais du coup c'est embêtant, dans ces conditions je ne vois pas de solution simple (je veux dire qui ne demande pas de faire de changements majeurs) pour implémenter un système qui fasse mieux que de la duplication bête et méchante.

Après, est-ce que c'est vraiment un si gros problème de conserver le comportement actuel du fork, et de l'étendre aux digressions avec quelques restrictions ?

- c'est conceptuellement moche, on est bien d'accord, mais s'il n'y avait que ça...

- je suis pas sûr que l'impact de la duplication sur la taille de la BDD soit si important. Un fork/une digression c'est généralement quelques dizaines de posts tout au plus, c'est pas vraiment énorme quand on compare ça à l'activité normale sur une journée (un topic très fréquenté peut facilement générer autant de nouveaux posts). Il faudrait que les gens se mettent à utiliser les digressions de façon intensive pour que la différence soit notable, je pense.

- des seuils de limitation bien choisis devraient permettre d'éliminer 99% des soucis, ça me paraît faisable de gérer manuellement les rares cas exceptionnels quand ils surviennent.

Et si vous faites comme les systèmes de fichiers GNU/Linux? Chaque post a un ID global (appelons-le "inode_num"), un topic n'est qu'une liste d'inode_nums (avec quelques attributs globaux supplémentaires: titre du topic, forum, catégorie), mais ces posts seraient affichés comme des posts distincts (des fichiers hardlinkés), avec en particulier des ./numéros distincts selon le topic (et ./n_topic-n_post et ./n'_topic-n'_post seraient tous deux des références valides vers le même post). On pourrait éventuellement afficher "reference count: 2" (comme le fait ls -l – si vous vous êtes toujours demandés ce que veut dire le mystérieux "1" que presque tous les fichiers ont dans ls -l, c'est ça). Éditer le post à un endroit l'éditerait à tous les endroits (comme pour les hardlinks GNU/Linux, si l'éditeur ne fait pas quelque chose de spécial), mais on pourrait aussi offrir une checkbox "Detacher" (CoW) lors de l'édition.

Le problème serait le même que pour ma solution à base de simili-liens symboliques (mais en pire, parce que ça ne concernerait pas que les posts forkés) : pour que ça fonctionne sans avoir un gros impact négatif sur les performances, il faudrait changer la structure de la base de données ; et probablement faire une revue complète du code, parce qu'une modification aussi fondamentale peut avoir plein d'effets de bord.

Zeph (./16) :
Il faut que je re-vérifie, mais je crois que le MySQL du serveur de yN est une version préhistorique qui ne supporte pas les vues

Ouch, si c'est le cas c'est vraiment vieux en effet >.<

Zeph (./16) :
Bon, il va falloir que je relise ta réponse à tête reposée

Version courte : ça fonctionne en gros comme un lien symbolique ^^

L'idée du lien symbolique est bonne, le seul problème qu'elle ne résout pas est celui de la duplication de contenu (mais comme je ne suis même pas sûr qu'il s'agisse d'un vrai problème j'imagine qu'on peut le mettre de côté). C'est une modification conséquente mais envisageable, qui en plus ouvrirait d'autres possibilités : il deviendrait par exemple possible de supprimer réellement un post (par exemple quand qqun décide de spammer un peu partout dans des sujets existants) plutôt que le palliatif actuel qui consiste à les rendre quasi-invisibles.

J'ai juste une petite crainte au niveau de l'impact sur les performances, puisque ça veut dire traverser une table de plus à chaque affichage d'une page de sujet. Mais bon, au minimum ça se teste, je vais essayer de faire quelques tentatives quand j'aurai un moment et voir ce que ça donne

Zeph (./22) :

J'ai juste une petite crainte au niveau de l'impact sur les performances, puisque ça veut dire traverser une table de plus à chaque affichage d'une page de sujet. Mais bon, au minimum ça se teste, je vais essayer de faire quelques tentatives quand j'aurai un moment et voir ce que ça donne

Si ton MySQL supporte les vues, ça gère plutôt pas mal au niveau perfs (en tout cas, de mon côté, j'ai eu à faire une vue pour pallier une grosse requête mal foutue, et je suis passé de plusieurs secondes la requête à un résultat immédiat ; cela dit, les volumes de données ne sont pas les mêmes...).

Je ne comprends pas trop pourquoi une vue aurait des meilleures performances ? Au coût de parsing de la requête près (qui doit être négligeable ici par rapport au volume de données à scanner) ça ne devrait absolument rien changer par rapport à modifier la requête, ou bien quelque chose m'échappe ?

Je suis loin d’être un expert en SQL, mais ayant eu quelque cours et lu des trucs, de mémoire les vue permettent au moteur des optimisations que tu ne peux pas faire avec les requêtes classiques.

Zeph (./24) :
Je ne comprends pas trop pourquoi une vue aurait des meilleures performances ? Au coût de parsing de la requête près (qui doit être négligeable ici par rapport au volume de données à scanner) ça ne devrait absolument rien changer par rapport à modifier la requête, ou bien quelque chose m'échappe ?

J'en ai été le premier surpris, mais effectivement, Godzil a raison, il y a des optimisations qui sont faites (je soupçonne le fait de créer des bases temporaires en mémoire qui gèrent les modifications des tables sources à la volée, mais je n'ai pas approfondi la chose).
En tout cas, dans les faits, c'est clair et net : une requête de plusieurs seconde lorsque lancée normalement qui devient immédiate lorsque la même requête est utilisée pour générer la vue (et ne pensant pas ça possible, j'ai repoussé l'idée d'une vue pendant des mois ; je le regrette un peu, à présent ^^).

Tu es sûr que tu n'as pas bénéficié de l'effet d'un cache en testant une requête similaire sur la même instance MySQL sans la redémarrer entre temps ? Parce que les tables temporaires, comme d'autres optimisations, n'ont a priori aucune raison d'être désactivées quand on fait une requête directe plutôt que de passer par une vue a priori. Si tu as des infos là-dessus ça m'intéresse parce que je n'ai pas du tout prévu d'utiliser des vues, en partant du principe qu'au niveau perf c'est quasiment identique (et comme toutes les requêtes sont générées via des DAO ça m'arrange bien, j'ai tout sauf envie de passer à des vues ).

[edit] Je n'ai pas cherché en détail, mais les quelques discussions que je trouve sur le sujet semblent également indiquer qu'il n'y a aucune raison d'avoir un gain de performance (exemple).

Normalement non, je ne redémarre jamais mes instances MySQL (et je pense même avoir testé plusieurs fois avec une même connexion - et ça restait plus lent).
Je vais voir rapidement si je trouve des infos sur le sujet

Bon, j'ai approfondi le truc :
Le cache de la requête semble se vider à chaque connexion par le serveur. Comme c'est utilisé par BusinessObjects, on dirait qu'il clôt puis rouvre les connexions à chaque opération (youhou !). Passer sous forme de vue fait que c'est MySQL qui conserve son propre cache de requête (donc ce n'est pas directement lié à l'utilisation des vues). Je passe quand-même de 1s (j'avais dû finir par arriver à optimiser la requête) à 0,0008s. Ce comportement est reproductible en lançant les requêtes en direct avec des scripts PHP et des connexions persistantes.

Par contre, il existe les vues materialisées et qui, a priori, fait exactement ce que j'indiquais dans mon message précédent : quand la table d'origine est mise à jour, la table temporaire l'est aussi à la volée. Inconvénient : j'imagine que ça doit prendre de l'espace en mémoire, et je ne sais pas comment ça réagit lors d'un redémarrage du serveur (je n'ai pas trop le temps de tester, là ).
Il y a aussi les vues classiques avec table temporaire, mais je n'ai pas non plus pu approfondir (d'autant que je pense que vu les volumes de yN, ça ne correspond pas du tout aux besoins)
Il y a des infos là, avec un petit bench :
https://openclassrooms.com/courses/administrez-vos-bases-de-donnees-avec-mysql/vues-materialisees

Si c'est un cache de requête (la forme tokenisée) alors je pense que l'impact est négligeable, la différence que tu trouves serait très étonnante (voire pas crédible du tout en fait ). Si c'est un cache de résultats alors je ne peux pas trop compter dessus pour yAronet : ça fonctionne si tu as quelques requêtes très couteuses qui sont répétées régulièrement, mais ici chaque requête vise potentiellement un sujet et des messages différents, donc le cache risque d'avoir un effet négligeable si ça n'est pas carrément négatif.

Merci pour le test et les infos en tout cas