threadedcomments et comment.user

Camille Bouiller · 25-03-2010 05:26:42

Bonjour,

J'utilise depuis peu le module
django-threadedcomments<http://github.com/ericflo/django-threadedcomments/>,
il marche plus ou moins bien. Le problème vient des requêtes qu'il me fait.

Par exemple il suffit que je fasse ne serait-ce qu'un {{ comment.user }}
(dans la boucle de mes commentaires donc), il me fait automatiquement une
requête par commentaire :

*0.10 SELECT* "auth_user"."id", "auth_user"."username",
> "auth_user"."first_name", "auth_user"."last_name", "auth_user"."email",
> "auth_user"."password", "auth_user"."is_staff", "auth_user"."is_active",
> "auth_user"."is_superuser", "auth_user"."last_login",
> "auth_user"."date_joined" *FROM* "auth_user" *WHERE*"auth_user"."id" = 1

*0.11 SELECT* "auth_user"."id", "auth_user"."username",
> "auth_user"."first_name", "auth_user"."last_name", "auth_user"."email",
> "auth_user"."password", "auth_user"."is_staff", "auth_user"."is_active",
> "auth_user"."is_superuser", "auth_user"."last_login",
> "auth_user"."date_joined" *FROM* "auth_user" *WHERE*"auth_user"."id" = 1

Imaginez sur un article de 100 commentaires qui génère pas mal
d'affichages.... J'ai cherché des solutions pour corriger ce problème, des
alternatives, et dans le domaine des commentaires "à niveaux" y'a pas grand
chose (à part mptt, qui a l'air un peu abandonné).

Du coup, je me demande si ça vaudrait pas le coup de développer un nouveau
module, qui pourrait aussi gérer la pagination (ou non) et le stockage du
commentaire parsé en bdd (car je préfère parser les commentaires à
l'enregistrement plutôt qu'à l'affichage...).

Qu'en pensez-vous ?

D'avance merci pour vos contributions à ce "débat".

Camille.

Rémy HUBSCHER · 25-03-2010 08:52:13

Tu as ce problème même en utilisant select_related ?

Le jeudi 25 mars 2010 à 00:26 -0400, Camille Bouiller a écrit :
> Bonjour,
>
> J'utilise depuis peu le module django-threadedcomments, il marche plus
> ou moins bien. Le problème vient des requêtes qu'il me fait.
>
>
> Par exemple il suffit que je fasse ne serait-ce qu'un
> {{ comment.user }} (dans la boucle de mes commentaires donc), il me
> fait automatiquement une requête par commentaire :
>
>
> 0.10 SELECT "auth_user"."id", "auth_user"."username",
> "auth_user"."first_name", "auth_user"."last_name",
> "auth_user"."email", "auth_user"."password",
> "auth_user"."is_staff", "auth_user"."is_active",
> "auth_user"."is_superuser", "auth_user"."last_login",
> "auth_user"."date_joined" FROM "auth_user" WHERE"auth_user"."id" = 1
>
> 0.11 SELECT "auth_user"."id", "auth_user"."username",
> "auth_user"."first_name", "auth_user"."last_name",
> "auth_user"."email", "auth_user"."password",
> "auth_user"."is_staff", "auth_user"."is_active",
> "auth_user"."is_superuser", "auth_user"."last_login",
> "auth_user"."date_joined" FROM "auth_user" WHERE"auth_user"."id" = 1
>
>
> Imaginez sur un article de 100 commentaires qui génère pas mal
> d'affichages.... J'ai cherché des solutions pour corriger ce problème,
> des alternatives, et dans le domaine des commentaires "à niveaux" y'a
> pas grand chose (à part mptt, qui a l'air un peu abandonné).
>
>
> Du coup, je me demande si ça vaudrait pas le coup de développer un
> nouveau module, qui pourrait aussi gérer la pagination (ou non) et le
> stockage du commentaire parsé en bdd (car je préfère parser les
> commentaires à l'enregistrement plutôt qu'à l'affichage...).
>
>
> Qu'en pensez-vous ?
>
>
> D'avance merci pour vos contributions à ce "débat".
>
>
> Camille.
>
>
>
> _______________________________________________
> django mailing list
> django _AT_ lists.afpy.org
> http://lists.afpy.org/mailman/listinfo/django

Olivier Meunier · 25-03-2010 09:42:26

Le 25/03/10 05:26, Camille Bouiller a écrit :
> Imaginez sur un article de 100 commentaires qui génère pas mal
> d'affichages.... J'ai cherché des solutions pour corriger ce problème, des
> alternatives, et dans le domaine des commentaires "à niveaux" y'a pas grand
> chose (à part mptt, qui a l'air un peu abandonné).

Sans mptt, il n'y a pas d'autre alternative que faire plein (trop) de
requêtes. Il existe des syntaxes spécifiques, type CONNECT BY PRIOR sur
Oracle, et même un standard pour ça sauf que personne ne l'applique
(PostgreSQL est en train ou l'a déjà fait, je sais plus).

mptt n'est pas très compliqué à implémenter une fois qu'on a pigé le
truc. La consultation d'un arbre est très simple (c'est tout l'intérêt)
et la mise à jour un peu plus compliqué si on veut qu'elle soit économe.

Je suis étonné que mptt soit à l'abandon, c'est dommage.

Camille Bouiller · 25-03-2010 19:04:58

@Rémy : il faudrait au moins que je sache où mettre select_related() dans le
module django-threadedcomments. Je ne sais pas du tout si ça vient
uniquement de ce module ou c'est un problème plus général de Django.

@Olivier : la dernière version est de Juin 2009. Niveau conception, j'aurais
bien vu la représentation intervallaire (mptt l'utilise sans doute ?) mais
je me demande si c'est adapté à des commentaires.

En fait, l'important est plutôt de savoir si en faisait {{ comment.user }},
en utilisant un module externe comme threadedcomments, va obligatoirement
faire une requête en boucle ? Si oui, ça serait plutôt embêtant.

Si l'utilité d'un système de commentaires comme ça, avec une pagination, se
faisait sentir, c'est sûr que je réflechirais à développer un tel module.
Avant ça, ça aurait été bien de connaître des alternatives. ^^

Camille.

2010/3/25 Olivier Meunier <om _AT_ neokraft.net>

> Le 25/03/10 05:26, Camille Bouiller a écrit :
>
> Imaginez sur un article de 100 commentaires qui génère pas mal
>> d'affichages.... J'ai cherché des solutions pour corriger ce problème, des
>> alternatives, et dans le domaine des commentaires "à niveaux" y'a pas
>> grand
>> chose (à part mptt, qui a l'air un peu abandonné).
>>
>
> Sans mptt, il n'y a pas d'autre alternative que faire plein (trop) de
> requêtes. Il existe des syntaxes spécifiques, type CONNECT BY PRIOR sur
> Oracle, et même un standard pour ça sauf que personne ne l'applique
> (PostgreSQL est en train ou l'a déjà fait, je sais plus).
>
> mptt n'est pas très compliqué à implémenter une fois qu'on a pigé le truc.
> La consultation d'un arbre est très simple (c'est tout l'intérêt) et la mise
> à jour un peu plus compliqué si on veut qu'elle soit économe.
>
> Je suis étonné que mptt soit à l'abandon, c'est dommage.
>
> --
> Olivier
>
> _______________________________________________
> django mailing list
> django _AT_ lists.afpy.org
> http://lists.afpy.org/mailman/listinfo/django
>

Olivier Meunier · 25-03-2010 23:56:20

Le 25/03/10 19:04, Camille Bouiller a écrit :
> @Olivier : la dernière version est de Juin 2009. Niveau conception, j'aurais
> bien vu la représentation intervallaire (mptt l'utilise sans doute ?) mais
> je me demande si c'est adapté à des commentaires.

MPTT, n'est rien d'autre que le petit nom en Anglais pour "Arbre
intervallaire". Comme je suis fainéant ce soir, je te laisse chercher la
signification de l'acronyme

Est-ce adapté à des commentaires ? Le volume de données peut devenir un
problème sauf si on réduit les arbres aux billets (donc, on bosse sur un
triplet, post_id, left, right).

Comme je le disais, MPTT est une solution très élégante pour stocker des
arbres dans une base de données. En plus, ça marche partout.

Côté select, c'est génial et ça va très vite. C'est les modifications
qui rendent tout ceci très intéressant. Beaucoup d'implémentations
simples se contentent de mettre à jour chaque noeud de l'arbre quand on
le modifie. C'est pas terrible niveau perf. C'est possible de le faire
en une seule requête dans le plupart des cas.

Pour Dotclear, j'avais fait une implémentation en PHP:
https://svn.dotclear.net/2.0/trunk/inc/core/class.dc.categories.php

Je pense que c'est tout à fait possible de faire un abstract model sur
cette base. Si j'avais pas de choses plus urgentes, comme un travail,
j'adorerai le faire Il me semble que David s'y était aussi intéressé.

> En fait, l'important est plutôt de savoir si en faisait {{ comment.user }},
> en utilisant un module externe comme threadedcomments, va obligatoirement
> faire une requête en boucle ? Si oui, ça serait plutôt embêtant.

Logiquement oui, c'est ça ou MPTT.

Pour relativiser, ce n'est pas toujours une hérésie de faire beaucoup de
requêtes SQL si celles-ci ne sont pas gourmandes.

Camille Bouiller · 26-03-2010 00:10:08

Ah c'est aussi ce que je me disais, merci pour la précision.

Je vais regarder du coté de MPTT, il y a d'ailleurs django-mptt-comments (le
dernier commit date d'un an), même si ça n'a pas l'air très utilisé. Ou je
pourrais développer ma propre alternative, à voir. Mais pour "paginer" un
arbre de commentaires, ça risque d'être complexe ?

Complètement d'accord avec toi pour le nombre de requêtes mais j'ai du mal à
penser que _juste_ pour savoir si l'auteur du commentaire est inscrit, il
faut une requête. Et je ne parle pas pour savoir s'il est admin... Et même
si je veux avoir les informations du profil d'un auteur de commentaire,
c'est pareil, une requête en plus.

Merci pour tes réponses précises en tout cas, ça me fait avancer dans ma
réflexion.

2010/3/25 Olivier Meunier <om _AT_ neokraft.net>

> Le 25/03/10 19:04, Camille Bouiller a écrit :
>
> @Olivier : la dernière version est de Juin 2009. Niveau conception,
>> j'aurais
>> bien vu la représentation intervallaire (mptt l'utilise sans doute ?) mais
>> je me demande si c'est adapté à des commentaires.
>>
>
> MPTT, n'est rien d'autre que le petit nom en Anglais pour "Arbre
> intervallaire". Comme je suis fainéant ce soir, je te laisse chercher la
> signification de l'acronyme
>
> Est-ce adapté à des commentaires ? Le volume de données peut devenir un
> problème sauf si on réduit les arbres aux billets (donc, on bosse sur un
> triplet, post_id, left, right).
>
> Comme je le disais, MPTT est une solution très élégante pour stocker des
> arbres dans une base de données. En plus, ça marche partout.
>
> Côté select, c'est génial et ça va très vite. C'est les modifications qui
> rendent tout ceci très intéressant. Beaucoup d'implémentations simples se
> contentent de mettre à jour chaque noeud de l'arbre quand on le modifie.
> C'est pas terrible niveau perf. C'est possible de le faire en une seule
> requête dans le plupart des cas.
>
> Pour Dotclear, j'avais fait une implémentation en PHP:
> https://svn.dotclear.net/2.0/trunk/inc/core/class.dc.categories.php
>
> Je pense que c'est tout à fait possible de faire un abstract model sur
> cette base. Si j'avais pas de choses plus urgentes, comme un travail,
> j'adorerai le faire Il me semble que David s'y était aussi intéressé.
>
>
> En fait, l'important est plutôt de savoir si en faisait {{ comment.user
>> }},
>> en utilisant un module externe comme threadedcomments, va obligatoirement
>> faire une requête en boucle ? Si oui, ça serait plutôt embêtant.
>>
>
> Logiquement oui, c'est ça ou MPTT.
>
> Pour relativiser, ce n'est pas toujours une hérésie de faire beaucoup de
> requêtes SQL si celles-ci ne sont pas gourmandes.
>
>
> --
> Olivier
> _______________________________________________
> django mailing list
> django _AT_ lists.afpy.org
> http://lists.afpy.org/mailman/listinfo/django
>

Camille Bouiller · 26-03-2010 05:59:58

Re,

J'ai réussi :
http://github.com/nephthys/django-threadedcomments/commit/2cf76e82e210498cc4fec6ad8a21c245d0733be0

Au final, c'est assez simple à faire. Comme tout le monde n'a pas forcément
besoin de cette jointure avec la table des membres, j'ai créé une variable
dans la config. J'espère que le développeur principal s'intéressera à mon
fork, ça pourra sûrement aider quelques personnes.

Camille.

2010/3/25 Camille Bouiller <aftercem _AT_ gmail.com>

> Ah c'est aussi ce que je me disais, merci pour la précision.
>
> Je vais regarder du coté de MPTT, il y a d'ailleurs django-mptt-comments
> (le dernier commit date d'un an), même si ça n'a pas l'air très utilisé. Ou
> je pourrais développer ma propre alternative, à voir. Mais pour "paginer" un
> arbre de commentaires, ça risque d'être complexe ?
>
> Complètement d'accord avec toi pour le nombre de requêtes mais j'ai du mal
> à penser que _juste_ pour savoir si l'auteur du commentaire est inscrit, il
> faut une requête. Et je ne parle pas pour savoir s'il est admin... Et même
> si je veux avoir les informations du profil d'un auteur de commentaire,
> c'est pareil, une requête en plus.
>
> Merci pour tes réponses précises en tout cas, ça me fait avancer dans ma
> réflexion.
>
> 2010/3/25 Olivier Meunier <om _AT_ neokraft.net>
>
>> Le 25/03/10 19:04, Camille Bouiller a écrit :
>>
>> @Olivier : la dernière version est de Juin 2009. Niveau conception,
>>> j'aurais
>>> bien vu la représentation intervallaire (mptt l'utilise sans doute ?)
>>> mais
>>> je me demande si c'est adapté à des commentaires.
>>>
>>
>> MPTT, n'est rien d'autre que le petit nom en Anglais pour "Arbre
>> intervallaire". Comme je suis fainéant ce soir, je te laisse chercher la
>> signification de l'acronyme
>>
>> Est-ce adapté à des commentaires ? Le volume de données peut devenir un
>> problème sauf si on réduit les arbres aux billets (donc, on bosse sur un
>> triplet, post_id, left, right).
>>
>> Comme je le disais, MPTT est une solution très élégante pour stocker des
>> arbres dans une base de données. En plus, ça marche partout.
>>
>> Côté select, c'est génial et ça va très vite. C'est les modifications qui
>> rendent tout ceci très intéressant. Beaucoup d'implémentations simples se
>> contentent de mettre à jour chaque noeud de l'arbre quand on le modifie.
>> C'est pas terrible niveau perf. C'est possible de le faire en une seule
>> requête dans le plupart des cas.
>>
>> Pour Dotclear, j'avais fait une implémentation en PHP:
>> https://svn.dotclear.net/2.0/trunk/inc/core/class.dc.categories.php
>>
>> Je pense que c'est tout à fait possible de faire un abstract model sur
>> cette base. Si j'avais pas de choses plus urgentes, comme un travail,
>> j'adorerai le faire Il me semble que David s'y était aussi intéressé.
>>
>>
>> En fait, l'important est plutôt de savoir si en faisait {{ comment.user
>>> }},
>>> en utilisant un module externe comme threadedcomments, va obligatoirement
>>> faire une requête en boucle ? Si oui, ça serait plutôt embêtant.
>>>
>>
>> Logiquement oui, c'est ça ou MPTT.
>>
>> Pour relativiser, ce n'est pas toujours une hérésie de faire beaucoup de
>> requêtes SQL si celles-ci ne sont pas gourmandes.
>>
>>
>> --
>> Olivier
>> _______________________________________________
>> django mailing list
>> django _AT_ lists.afpy.org
>> http://lists.afpy.org/mailman/listinfo/django
>>
>
>

Django-fr

Forum

#1 25-03-2010 05:26:42

threadedcomments et comment.user

#2 25-03-2010 08:52:13

Re : threadedcomments et comment.user

#3 25-03-2010 09:42:26

Re : threadedcomments et comment.user

#4 25-03-2010 19:04:58

Re : threadedcomments et comment.user

#5 25-03-2010 23:56:20

Re : threadedcomments et comment.user

#6 26-03-2010 00:10:08

Re : threadedcomments et comment.user

#7 26-03-2010 05:59:58

Re : threadedcomments et comment.user

Pied de page des forums