FusionForge de l'ADULLACT: openADS : [#8859] Listings: Pagination incohérente quand le tri par default laisse une liberté à la BD

Date :
23/06/2017 22:45

Priorité :
3

État :
Closed

Proposé par :
Victor Grousset (tuxayo)

Confié à :
Victor Grousset (tuxayo)

Version cible :
4.3.0

Version concernée :
4.1.0

Résumé :
Listings: Pagination incohérente quand le tri par default laisse une liberté à la BD

Description détaillée
C'est à dire quand les critères ne déterminent pas un ordre unique. Par exemple, trier uniquement sur une date. Du coup en fonction des pages, l'ordre n'est pas le même. Car en autres, le SGBD en fonction des offsets différents peut planifier les requêtes différemment. Et donc si le critère de tri laisse une liberté, l'ordre peut être différent. (La norme SQL ne garantie pas l'ordre dans ce cas donc ça peut être un piège dans toutes les paginations avec tout les SGBD) https://stackoverflow.com/questions/13580826/postgresql-repeating-rows-from-limit-offset/30776464#30776464 [Listings affectés] A. Demandes d'avis B. Instruction → Dossiers à qualifier C. Instruction → Commission(s) D. Instruction → Consultation(s) [Reproduire] - A - en tant que l'utilisateur consu - lier 'consudi' à tout les services TRUNCATE TABLE lien_service_om_utilisateur; -- ça ne devrait pas faire d'effet de bords gênants INSERT INTO lien_service_om_utilisateur (lien_service_om_utilisateur,om_utilisateur,service) SELECT nextval('lien_service_om_utilisateur_seq'),'6', service FROM service; - ajouter plus d'une 15ne de consultations sur un DI - maintenant, consudi devrait avoir plein de demandes en cours car pleins de ses services ont étés consultés - et on devrait en trouver en commun entre les pages (et peut-être que certains ne serons sur aucune page) - B - en tant que l'utilisateur qualif - créer 3 dossiers, peut importe le type - aller dans «dossiers à qualifier» - WIP: limiter la pagination à 2 lignes Créer dossier_qualifier_qualificateur.form.php Pour surcharger ce que le framework fait et changer la pagination C'est le même travail que pour ajouter le ORDER BY donc ça n'est pas perdu. Dans dossier_qualifier.inc.php ajouter: $serie=2; - Créer au plus 10 dossiers (ça doit marcher avec moins) - ouvrir plusieurs onglets sur la liste - les mettre sur des pages différentes - et on devrait trouver des enregistrements en commun entre les pages - C - en tant que l'utilisateur admin - créer un type de commission: /scr/form.php?obj=commission_type&action=0 - en tant que l'utilisateur instr - ouvrir les outils réseau de Firefox (Ctrl-Maj-Q) - créer une commission - sur la requête POST correspondante, faire clic-droit → Copy as cURL - coller dans un terminal - enlever le paramètre "&form_resubmit_identifier=XXXXXXXXXXXXXXXXXXXXXXXX"* - ce qui permet d'envoyer la commande/requête pleins de fois d’affilés et d'avoir facilement des dizaines de commissions - ouvrir plusieurs onglets sur la liste - les mettre sur des pages différentes - et on devrait trouver des enregistrements en commun entre les pages - D - en tant que l'utilisateur instr - ajouter plus d'une 15ne de consultations sur un DI - maintenant dans l'onglet consultations, la pagination est utilisée - et on devrait trouver des enregistrements en commun entre les pages (et peut-être que certains ne serons sur aucune page) [Tâches liées mais repoussées] - 1 Pas de problèmes avec les tri manuel - 1 Autres listing potentiellement bugués au vu du code. - dossier_instruction.inc.php:139 $tri= "order by b.date_depot ASC"; - gen/dossier.inc.php:197 (donc côté framework) $tri="ORDER BY dossier.annee ASC NULLS LAST";
C'est à dire quand les critères ne déterminent pas un ordre unique. Par exemple, trier uniquement sur une date. Du coup en fonction des pages, l'ordre n'est pas le même. Car en autres, le SGBD en fonction des offsets différents peut planifier les requêtes différemment. Et donc si le critère de tri laisse une liberté, l'ordre peut être différent. (La norme SQL ne garantie pas l'ordre dans ce cas donc ça peut être un piège dans toutes les paginations avec tout les SGBD) https://stackoverflow.com/questions/13580826/postgresql-repeating-rows-from-limit-offset/30776464#30776464 [Listings affectés] A. Demandes d'avis B. Instruction → Dossiers à qualifier C. Instruction → Commission(s) D. Instruction → Consultation(s) [Reproduire] - A - en tant que l'utilisateur consu - lier 'consudi' à tout les services TRUNCATE TABLE lien_service_om_utilisateur; -- ça ne devrait pas faire d'effet de bords gênants INSERT INTO lien_service_om_utilisateur (lien_service_om_utilisateur,om_utilisateur,service) SELECT nextval('lien_service_om_utilisateur_seq'),'6', service FROM service; - ajouter plus d'une 15ne de consultations sur un DI - maintenant, consudi devrait avoir plein de demandes en cours car pleins de ses services ont étés consultés - et on devrait en trouver en commun entre les pages (et peut-être que certains ne serons sur aucune page) - B - en tant que l'utilisateur qualif - créer 3 dossiers, peut importe le type - aller dans «dossiers à qualifier» - WIP: limiter la pagination à 2 lignes Créer dossier_qualifier_qualificateur.form.php Pour surcharger ce que le framework fait et changer la pagination C'est le même travail que pour ajouter le ORDER BY donc ça n'est pas perdu. Dans dossier_qualifier.inc.php ajouter: $serie=2; - Créer au plus 10 dossiers (ça doit marcher avec moins) - ouvrir plusieurs onglets sur la liste - les mettre sur des pages différentes - et on devrait trouver des enregistrements en commun entre les pages - C - en tant que l'utilisateur admin - créer un type de commission: /scr/form.php?obj=commission_type&action=0 - en tant que l'utilisateur instr - ouvrir les outils réseau de Firefox (Ctrl-Maj-Q) - créer une commission - sur la requête POST correspondante, faire clic-droit → Copy as cURL - coller dans un terminal - enlever le paramètre "&form_resubmit_identifier=XXXXXXXXXXXXXXXXXXXXXXXX"* - ce qui permet d'envoyer la commande/requête pleins de fois d’affilés et d'avoir facilement des dizaines de commissions - ouvrir plusieurs onglets sur la liste - les mettre sur des pages différentes - et on devrait trouver des enregistrements en commun entre les pages - D - en tant que l'utilisateur instr - ajouter plus d'une 15ne de consultations sur un DI - maintenant dans l'onglet consultations, la pagination est utilisée - et on devrait trouver des enregistrements en commun entre les pages (et peut-être que certains ne serons sur aucune page) [Tâches liées mais repoussées] - 1 Pas de problèmes avec les tri manuel - 1 Autres listing potentiellement bugués au vu du code. - dossier_instruction.inc.php:139 $tri= "order by b.date_depot ASC"; - gen/dossier.inc.php:197 (donc côté framework) $tri="ORDER BY dossier.annee ASC NULLS LAST";

Commentaires (6)
Pièces jointes
Modifications (3)

Message
Date : 06/07/2017 15:41 Expéditeur : Victor Grousset Autres listings potentiellement bugués au vu du code: - gen/sql/pgsql/demandeur.inc.php (donc côté framework) $tri="ORDER BY demandeur.type_demandeur ASC NULLS LAST"; - sql/pgsql/demandeur.inc.php (ne surcharge pas le gen)
Date : 06/07/2017 15:29 Expéditeur : Victor Grousset Autres listings potentiellement bugués au vu du code: - petitionnaire.inc.php: 53 $tri="ORDER BY demandeur.type_demandeur ASC NULLS LAST"; - petitionnaire_frequent.inc.php (inclu petitionnaire.inc.php)
Date : 05/07/2017 14:52 Expéditeur : Sofien TIMEZOUAGHT Bonjour, L'ajout d'un tri par défaut sur certain lisitng afin d'éviter le problème de pagination, est terminé. Merge dans la branche d'intégration : → https://adullact.net/scm/viewvc.php?view=rev&root=openfoncier&revision=6998 Cordialement, -- Sofien TIMEZOUAGHT http://www.atreal.fr
Date : 26/06/2017 18:19 Expéditeur : Victor Grousset [Listings affectés] E. Demandes d'avis → Export
Date : 26/06/2017 18:14 Expéditeur : Victor Grousset Autres listing potentiellement bugués au vu du code: - commission.inc.php: $tri="ORDER BY commission.date_commission DESC NULLS LAST"; - gen/sql/pgsql/dossier_commission.inc.php:64 (donc côté framework) $tri="ORDER BY dossier.annee ASC NULLS LAST";
Date : 26/06/2017 14:57 Expéditeur : Victor Grousset lier 'consudi' à tout les services → lier 'consu' à tout les services

Pas de documents joints

Champ	Ancienne valeur	Date	Par
status_id	Open	05/07/2017 14:52	Sofien TIMEZOUAGHT
close_date	Aucun(e)	05/07/2017 14:52	Sofien TIMEZOUAGHT
assigned_to	none	05/07/2017 14:52	Sofien TIMEZOUAGHT

Powered By FusionForge Collaborative Development Environment

Charte d'utilisation / Nous contacter / Mentions légales

Haut de page