Meta ticket : le problème de la migration des structures

Hop,

avec les améliorations ergonomiques sur la config des traitements / les saisies, on doit parfois migrer la structure des champs traitements et/ou saisies (très rarement dans le second cas, c'est arrivé une fois en 10 ans).

Dans l'idéal, on devrait se passer de ces migrations, parce que

1. Il faudrait mieux anticiper
2. En cas de changement, on peut imaginer une migration "progresive" à la volée de la nouvelle configuration

Mais c'est pas tjr possible.

Pour l'heure je compte : https://git.spip.net/spip-contrib-extensions/formidable/-/blob/master/formidable_administrations.php?ref_type=heads#L254 https://git.spip.net/spip-contrib-extensions/formidable/-/blob/master/formidable_administrations.php?ref_type=heads#L284 https://git.spip.net/spip-contrib-extensions/formidable/-/blob/master/formidable_administrations.php?ref_type=heads#L316 https://git.spip.net/spip-contrib-extensions/formidable/-/blob/master/formidable_administrations.php?ref_type=heads#L352 https://git.spip.net/spip-contrib-extensions/formidable/-/blob/master/formidable_administrations.php?ref_type=heads#L476avec https://git.spip.net/spip-contrib-extensions/formidable/-/blob/master/formidable_administrations.php?ref_type=heads#L498

La plupart sont des migrations AVANT qu'on passe en json, mais pas toutes.

On a 2 problèmes avec les migrations

1. D'une part, le problème de perf/timeoute si on a bcp de formulaires, mais pour l'heure j'ai l'impression que même @nicod avec ses 20 000 formulaires n'y a jamais été confronté historiquement
2. D'autre part ce foutu bug sur les chemins mal initiés au moment de la maj à des plugins, qui fait qu'on ne peut pas utiliser formidable_serialize.

Dans le cas de 2, la résolution de #263 (closed) devrait en théorie résoudre le problème. Mais en fait pas totalement. Imaginons en effet un site avec un plugin formidable dont la meta base est 1.4.2. Formidable est mis à jour pour ce site avec meta-base en 1.6.3. Et bien il faudrait appliquer formidable_traitement_email_activer_responsable() avant meme que les traitements n'aient été convertis par cron en json. Et donc on aurait besoin de formidable_serialize.

Plusieurs solutions possibles :

• tant pis, on assume cela, on sait qu'on a un bug et c'st comme cela
• on procède autrement lorsqu'il faut migrer des formulaires a. En plus d'avoir une meta qui donne l'état des tables, on a pour chaque formulaire une meta qui donne l'état des traitements / des saisies b. On applique les migrations formulaire par formulaire "à la volée" de l'affichage des formulaires, avec une fonction spécifique appelé au tout début du _charger

Ca complexifie un peu le chargement, mais éviterait des soucis.

Mais bon, peut être que je me prend trop le chou, et que finalement bah heu... on peut rester comme c'est actuellement.