Produits Entr'ouvert » w.c.s.

Mais je ne parviens pas à reproduire le plantage dans nos tests :

--- a/tests/backoffice_pages/test_all.py
+++ b/tests/backoffice_pages/test_all.py
@@ -4397,6 +4397,10 @@ def test_inspect_page(pub, local_user):
     upload.receive([b'hello world'])
     formdata.data['4'] = upload
     formdata.user_id = local_user.id
+    formdata.workflow_data = {
+        'foo': 'xxx',
+        'foo_bar': 'yyy',
+    }
     formdata.store()

     from wcs.admin.settings import UserFieldsFormDef

se passe sans problème alors que j'imaginais un crash sur la visite de la page d'inspect un peu en dessous :

   resp = login(get_app(pub)).get(formdata.get_url(backoffice=True), status=200)
   resp = resp.click('Data Inspector')

Mon analyse du pb doit donc être fausse...

J'ai trouvé le cas qui pose problème :

--- a/tests/backoffice_pages/test_all.py
+++ b/tests/backoffice_pages/test_all.py
@@ -4397,6 +4397,12 @@ def test_inspect_page(pub, local_user):
     upload.receive([b'hello world'])
     formdata.data['4'] = upload
     formdata.user_id = local_user.id
+    formdata.workflow_data = {
+        'foo': {
+            'bar_coin': 'yy',
+        },
+        'foo_bar': 'xx',
+    }
     formdata.store()

Crash du test :

[2021-03-02 23:31:17] exception caught
Exception:
  type = '<class 'KeyError'>', value = ''form_workflow_data_foo_bar_coin''

Stack trace (most recent call first):
  File "/home/thomas/src/wcs/wcs/qommon/substitution.py", line 219, in __getitem__
   217                         # TypeError will happen if indexing is used on a string
   218                         if i == 1:
>  219                             raise KeyError(key)
   220                     else:
   221                         parts = parts[i:]

  locals: 
     __class__ = <class 'wcs.qommon.substitution.CompatibilityNamesDict'>
     current_dict = 'xx'
     i = 1
     key = 'form_workflow_data_foo_bar_coin'
     part = 'coin'
     parts = ['coin']
     self = {'form': <wcs.variables.LazyFormData object at 0x7f4dacbd7700>, 'attachments': <wcs.workflows.AttachmentsSubstitutionProxy object at 0x7f4dacbd7400>, 'foo_bar': 'xx', 'foo_bar_coin': 'yy'}

(jenkins va au moins péter sur black)

Sur jabber :

« – ouch... parts = parts[i:] dans le for i in range(len(parts), 0, -1) ... ça fait peur non ?
– il est dans le if i == 1, donc c'est la dernière itération. je peux ajouter un break si tu veux.
– si c'est possible c'est bien. »

Et de façon plus générale on pourrait réfléchir si on veut vraiment aller vers ça, i.e. avec quelque chose comme :

+    formdata.workflow_data = {
+        'foo': {
+            'bar_coin': 'toto',
+        },
+        'foo_bar': {
+            'coin': 'tata',
+        },
+    }

Alternativement on pourrait faire en sorte d’empêcher qu’on se retrouve avec des espaces de nommage partageant un préfixe commun ('foo' dans l’exemple ici.)

Paul Marillonnet a écrit :

Et de façon plus générale on pourrait réfléchir si on veut vraiment aller vers ça, i.e. avec quelque chose comme :

Oui en cas d'ambiguité il faudra trouver/planter/choisir-au-pif, mais là je suis chez un client dans une situation sans ambiguité et avec ce bogue.

Alternativement on pourrait faire en sorte d’empêcher qu’on se retrouve avec des espaces de nommage partageant un préfixe commun ('foo' dans l’exemple ici.)

Dans mon cas c'est la réponse d'un webservice qui renvoie du JSON structuré valable et logique... c'est nous décidons de l’aplatir et créons la difficulté. Le problème n'existait pas à l'origine, il est arrivé avec les optimisations lazy (parfaitement nécessaires).

Bref, va falloir creuser :)

(reste possible d'utiliser des points, si ça a une espèce d'urgence, c'est-à-dire ça va au-delà de l'affichage de page /inspect qui ne marche pas).

C'est un algorithme de recherche avec retour en arrière qui est nécessaire, parce que là on déscend linéairement du moins profond au plus profond en prenant la solution la plus courte longue à chaque niveau (si foo matche je descend dans foo, à mince y a pas bar dedans je m'arrête, au lieu de remonter d'un cran pour trouver foo_bar).

J'ai poussé une branche avec ce fonctionnement. J'ai gardé l'ordre actuel du préfixe le plus long au plus court, mais je pense que ce serait plus logique dans l'autre sens ([['form', 'var', 'truc_muche']], plutôt que [['form_var_truc_muche'], ['form_var_truc', 'muche'], ['form_var', 'truc_muche'], ..., ['form', 'var', 'truc_muche']]), à vrai dire l'ordre idéal ce serais le plus court, le plus long puis les autres préfixes.

Donc actuellement {'foo_bar': {'coin': 1}} va cacher {'foo': {'bar_coin': 2}}.

Benjamin,

-                        # TypeError will happen if indexing is used on a string

je garderais ce commentaire, il est là parce que j'ai trouvé utile rappel que le TypeError qu'on attrape vient de ce moment.

Frédéric Péters a écrit :

je garderais ce commentaire, il est là parce que j'ai trouvé utile rappel que le TypeError qu'on attrape vient de ce moment.

Ok, branche à jour.