Produits Entr'ouvert » w.c.s.

Exemples de code repéré pouvant correspondre à cette requête:

# wcs/admin/forms.py
        # remove existing shared views
        for view in get_publisher().custom_view_class.select():
            if view.match(user=None, formdef=self.formdef):
                view.remove_self()

# wcs/backoffice/management.py
    def get_custom_views(self, criterias=None):
        for view in get_publisher().custom_view_class.select(clause=criterias):
            if view.match(get_request().user, self.formdef):
                yield view
    def get_formdata_sidebar(self, qs=''):
        r = TemplateIO(html=True)
        r += htmltext('<ul id="sidebar-actions">')
        r += self.get_formdata_sidebar_actions(qs=qs)
        r += htmltext('</ul>')
        views = list(self.get_custom_views())
        # ...

    def save_view(self):
        # ...
            for view in self.get_custom_views():
                if view.id == custom_view.id:
                    continue
                if custom_view.visibility == view.visibility and view.is_default:
                    view.is_default = False
                    view.store()
    # ....
    def _q_lookup(self, component):
        if component == 'ics':
            return self.ics()

        if not self.view:
            for view in self.get_custom_views():
                if view.get_url_slug() == component:
                    return self.__class__(formdef=self.formdef, view=view)

Je vais tenter d'identifier si il y a des requêtes web qui sont plus fréquentes que les autres.

C'est possiblement un détail mais je vois une condition if self.formdef_type != formdef.xml_root_node: dans la fonction def match( que tu as remplacée par ton .select. Est-ce que ça ne risque pas de poser problème ?

Note : cette requête représente 25% du temps d'exécution PostgreSQL total cet après-midi sur la prod de toulouse. Donc il y a un vrai intérêt à l'identifier et à l'éliminer.

Je ne suis pas totalement à l'aise avec ça à deux jours de la mise en prod, ça demande un effort de relecture difficile.

En fait 1/ je ne prendrais pas 0001, qui concerne du code d'import/export, pas sensible, risque inutile.

0002 oui d'accord

0003 en fait ce que je voulais dire dans la discussion c'était qu'on pouvait sans risque déplacer le filtre sur les colonnes formdef_type/formdef_id vers l'SQL, mais garder l'appel à la méthode match() pour vérifier l'appartenance.

0003 en lisant j'ai l'impression qu'il fait l'inverse, et perd en chemin la vérification formdef_type/formdef_id.

Par ailleurs je regarde maintenant dans la db et je compte pour une seule démarche 579 vues personnalisées, donc je me dis que j'étais trop naïf à espérer nous en sortir avec juste formdef_type/formdef_id, que le reste est à prendre aussi.

Mais que peut-être ça ne sera pas assez et qu'en fait il y a quelque part de base un problème chez un utilisateur, qui à lui seul a 512 de ces 579 vues, toutes avec le même nom, et les slugs tous-les-dossiers, tous-les-dossiers-2, tous-les-dossiers-3... tous-les-dossiers-512.

Cet utilisateur aura encore des problèmes, il y a sans doute quelque chose dans l'UI qui pose problème.

Dans l'immédiat donc, j'éliminerais 0001 de la branche, 0002 ok (mais retirer la majuscule au préfixe du message de commit), 0003 ajouter le Equal('formdef_type', ...), Equal('formdef_id', ...) qui me semble manquer (dans le get_custom_views(); je voyais vaguement quelque chose comme ça, pas testé :

    def get_custom_views(self, criterias=None):
        for view in get_publisher().custom_view_class.select(
            clause=[
                Equal('formdef_type', self.formdef_class.xml_root_node),
                Equal('formdef_id', str(self.formdef_class.id)),
            ]
            + (criterias or [])
        ):
            if view.match(get_request().user, self.formdef):
                yield view

C'est plus que limite côté calendrier mais c'est une optimisation qui aurait été bienvenue pour la mise en production de ce soir.

Automatic expiration