Produits Entr'ouvert » Passerelle

Est-ce que ça doit vraiment être un endpoint séparé, la prise en charge de projection/where/dictinct/order ne pourrait pas aller dans l'endpoint data existant ?

Et les paramètres acceptés par celui-ci seraient réinterprétés pour alimenter le "where". (comme quand il y a eu l'ajout de filtres et que le paramètre "q" a été réinterprété en leurs termes).

Ensuite, il faudra une présentation dans csvdatasource_detail.html.

Je me suis dit que c'était bien plus simple et moins casse-gueule de développer un nouveau endpoint et de migrer dessus au besoin, et puis surtout je ne suis pas certain que permettre d'envoyer des expressions python soit très judicieux, c'est plus une preuve de concept. Une version plus utile ne permettrait de définir ces requêtes que dans passerelle. En l'état ce nouveau endpoint fait déjà tout ce que fait l'autre (et je peux éventuellement ajouter le support de q

En fait si je comprends mieux, c'était un premier patch développé en local comme proof of concept et posté ici pour inviter l'un ou l'autre à partir de là pour le terminer, requêtes stockées comme tu l'écris, mes commentaires ou pas, etc. ?

Non je pense que je vais devoir le finir si on veut pas que Mike devienne fou avec les formulaires SVE (mais si quelqu'un a une autre idée pour gérer un workflow à 200 et quelques communes traitantes qu'il le dise), disons que ça ne me dérangerait pas d'avoir des endpoints en béta dans passerelle, le temps qu'on comprenne bien ce qu'on fait là. Là ce qui m'inquiète c'est que si la datasource est publique et que quelqu'un envoie '100**232323233' dans une condition, ça va faire partir le worker en sucette. Donc déjà je n'autorisera ce endpoint qu'à un utilisateur authentifié quelque soit le contrôle d'accès en place. Je vois bien plusieurs itérations se faire, ce endpoint dans un premier temps, et une version avec requêtes purement définies coté passerelle ensuite histoire d'avancer vite.

Et pour être exact ça a été en partie développé dans le train depuis Lyon hier.

J'ai juste un souci avec le changement where -> filters, en fait un seul filtre est possible (le test se fait ensuite sur le premier résultat de la séquence new_row), il ne faudrait donc pas utiliser get_list('filters') mais juste faire stream_expresions([query.filter], ...) car de toute façon le résultat des autres expressions filters sont ignorés.

Il manque le fichier csvdatasource/query_form.html.

La possibilité d'écraser les variables issues des lignes du CSV via **kwargs me parait potentiellement gênante, pour limiter ça je verrai plutôt l.224:

row_vars['query'] = kwargs

Ça oblige à faire des query['xxx'] dans les expressions, ce n'est pas mortel.

J'attache un patch avec de la validation des expressions pour le formulaire.

Sinon ack à tout, plus tard comme dans w.c.s. on pourra proposer un module evalutils (pour jouer avec les dates ou les valeurs numérique formatées à la française notamment).

C'est bien sûr sous-performant mais modifié comme ça, on pourrait avoir plusieurs filtres, non ?

         filters = query.get_list('filters')
         if filters:
-            data = [row for new_row, row in stream_expressions(filters, data, kind='filters')
-                    if new_row[0]]
+            for clause in filters:
+                data = [row for new_row, row in stream_expressions([clause], data, kind='filters')
+                        if new_row[0]]

Ack, je mettrai à jour le sictiam pour que Mike béta-test tout ça.