Bonjour,
J'ai mis taize.fr à jour (SVN [12223]). Jusqu'à maintenant la seuele remarque des utilisateurs est qu'il y a sur la page /ecrire/?exec=accueil une liste monstre des "Modifications des articles" qui donne des liens sur plus de 40 lignes pour accéder à 5401 modifications.
C'est trop !
Paolo
J'ai mis taize.fr à jour (SVN [12223]). Jusqu'à maintenant la seuele
remarque des utilisateurs est qu'il y a sur la page /ecrire/?exec=accueil
une liste monstre des "Modifications des articles" qui donne des liens sur
plus de 40 lignes pour accéder à 5401 modifications.C'est trop !
Il faut de manière générale qu'on revoie tous les systèmes de
"pagination" dans l'espace privé car ils sont en effet monstrueux.
Faire un ticket SVP.
Dans l'intervalle tu peux :
* ajouter un LIMIT dans la requête qui les affiche ? (à mon avis c'est
le meilleur plan)
* supprimer les anciennes révisions dans la base de données ?
* autre en php
-- Fil
bonjour,
tu veux dire qu'il n'y a pas de pagination ?
il faut squeletiser, ce qui permet d'utiliser la {pagination} et de ne maintenir qu'un code ...
Fil wrote:
Il faut de manière générale qu'on revoie tous les systèmes de
"pagination" dans l'espace privé car ils sont en effet monstrueux.
Faire un ticket SVP.
http://trac.rezo.net/trac/spip/ticket/1428
* supprimer les anciennes révisions dans la base de données ?
J'aimerais bien savoir quelle requête exécuter pour enlever les révisions antérieur à une date donnée.
Pour commencer, je suppose :
DELETE FROM spip_versions WHERE date < '2008-01-01'
(mais est-ce que le champ 'permanent' indique que cet enregistrement doit rester intact ?)
Et puis comment effacer de spip_versions_fragments les lignes qui y correspondent ?
En regardant la liste des champs ce n'est pas évident - du moins pour moi 
Paolo
A mon avis, on peut insérer la limite nous-même dans le core dès à présent. Sur la page «accueil», l'affichage du suivi des révisions, ça sert à avoir un suivi des révisions, justement, donc quelque chose d'exploitable. Limiter aux 100 dernières révisions devrait être largement suffisant. Au-delà, de toute façon, l'information ne sert rigoureusement à rien.
Ensuite, d'accord avec les autres, oui on finira par passer les affichages de listes en squelettes, avec une pagination bien fichue. Mais d'ici là, limiter manuellement le nombre d'affichages de révisions sur "accueil" me semble parfaitement logique avec le pourquoi c'est fait (et ne relève donc pas de la bidouille vite torchée).
Au sujet de la squelletisation des listes, s'il y en a qui se lancent de leur côté, je signale qu'au passage, il serait bon de gagner quelques fonctionnalités super-pratiques: un pavé de recherche à déclenchement immédiat (onkeypressed) dans la liste, et des entêtes de listes cliquables pour forcer le classement selon un autre critère (par date, par ordre alphabétique, et inverse).
A*
Eh bien vérification faite il y avait une limite à 149 ici... elle a
sauté avec le passage à sql_countsel(), ce qui d'ailleurs révèle un
bug dans sql_countsel.
L'appel est le suivant :
$total = sql_countsel($req_from, $req_where, '', "0, 149");
(ecrire/inc/suivi_versions.php ligne 177)
et la requête faite (?var_profile=oui) est :
SELECT COUNT(*)
FROM `spip`.spip_versions
AS versions
LEFT JOIN `spip`.spip_articles
AS articles
ON versions.id_article = articles.id_article
WHERE versions.id_version > 1 AND articles.statut
IN ('prop','publie')
LIMIT 0, 149
où la limite ne s'applique pas
Corrigé par [12239] et [12240], en corrigeant sql_countsel() dans le
cas où il y a un LIMIT
A reporter peut-être en pg et sqlite ??
-- Fil
C'est celui qu'on a découvert l'autre jour en fait.
Mais il ne faut pas intervenir dans req/mysql parce que le bug va rester dans les autres portages,
il faut supprimer le paramètre LIMIT dans l'API puisqu'il est trompeur.
Il n'y a que 4 cas qui l'utilisent, je m'occupe de les réécrire.
Committo,Ergo:Sum
PS: désolé pour 12208, j'ai été trop pressé de mettre au carré.
il faut supprimer le paramètre LIMIT dans l'API puisqu'il est trompeur.
Il n'y a que 4 cas qui l'utilisent, je m'occupe de les réécrire.
pourquoi ? la correction est cool, non ?
-- Fil
Comme tu as dit elle est a multipliée par le nombre de portages, donc elle n'est pas cool.
Committo,Ergo:Sum
il faut supprimer le paramètre LIMIT dans l'API puisqu'il est trompeur.
Il n'y a que 4 cas qui l'utilisent, je m'occupe de les réécrire.pourquoi ? la correction est cool, non ?
Comme tu as dit elle est a multipliée par le nombre de portages, donc elle
n'est pas cool.
C'est le principe du portage, ça : en l'occurrence il n'y a que 2
copier-coller à faire pour "porter" la correction, à condition que PG
et SQLite se comportent bien comme MySQL. M'enfin fais comme tu le
sens.
-- Fil
... et tous les portages à suivre, ce qu'on ne peut savoir.
Ce "a condition" est porteur de bug, j'ai eu une mauvaise idée avec cet argument LIMIT, il faut en prendre acte et le supprimer avant l'officialisation.
Et puis un point important: les fichiers de req/ sont un portage, oui, mais base/abstract_sql n'en est pas un: c'est une interface de programmation qui ne doit pas préter à confusion ou doute.
Committo,Ergo:Sum