Le Mad Blog

Je me suis retrouvé il y a quelques temps avec une problématique, remplacer une chaine par une autre dans un attribut CharField d’un model django.

La première possibilité était de faire tout simplement une belle boucle sur la totalité de mes instances de module, faire le remplacement en python et sauvegarder la nouvelle valeur.

Sauf que j’avais quasiment un million d’objet et que je n’avais pas envie que cela prenne des plombes. Et puis c’était un peu moche.

Du coup j’ai un peu fouillé et miracle, j’ai trouvé une solution que voici.

On commence par définir la fonction de remplacement, tout en django et en SQL.

from django.db.models import F, Func, Value

def replace_func(field_name, old_str, replace_str):

    return Func(

        F(field_name),

        Value(old_str), Value(replace_str),

        function='replace'

    )

Ensuite, il n’y a quasiment plus rien à faire. On va simplement appeler update sur tout les objets et utiliser replace_func.

Par exemple :

MonModele.objects.filter(CONDITIONS).update(

    champ_a_modifier=replace_func("champ_a_modifier",

                                  "str_que_lon_veut_remplacer",

                                  "nouvelle_chaine_de_caractere")

Et voila, c’est fini.

Je me suis enfin lancé dans l’écriture d’une app django gérant les badges (ou les succès si vous préférez). L’objectif étant de pouvoir réécrire de zéro histoires de rôlistes. L’idée était de tenter de faire une vraie app django, en mode réutilisable, histoire que peut-être des gens puissent trouver intéressant de l’utiliser.

Je me suis retrouvé avec deux problèmes concernant mes tests :

• Souvent on gagne un badge quand on a créé suffisamment de chose (comme des checkin, des billets de blogs ou des contributions diverses). Sauf que je ne voulais pas créer dans mon app des models ne servant à rien, juste pour pouvoir en créer lors de mes tests.
• Je voulais pouvoir créer des badges se gagnant sur un critère du style ‘être venu un certain nombre de fois sur une URL.’ Donc mettre en place des décorateurs sur des vues. Mais là encore, je ne voulais pas avoir à créer des vues dans mon application rien que pour les tests.

Au final, en lisant un peu de doc, j’ai réussi à faire ce que je voulais.

Tester un décorateur sans créer des  vues inutiles dans son app.

Je savais déjà comment forger des requests avec la RequestFactory. Par contre pour créer des vues, je n’en avais pas la moindre idée.. Une petite question plus tard, Foxmask m’a indiqué un lien qui allait me donner la solution que je cherchais. (le voici) Il suffisait au final d’utiliser mock pour créer, directement dans mes tests, une fausse vue que j’allais pouvoir décorer.
Une dernière subtilité, comme vous le verrez dans le lien novapost (ou dans mon code), si vous utilisez wraps pour créer votre décorateur, il faudra ajouter l’argument assigned=available_attrs(view_func) à votre appel à wraps (tout comme django le fait). Cela sera nécessaire pour pouvoir utiliser votre décorateur en mode fonction, ce que vous devrez faire dans vos tests, à cause d’un bug python 2 (celui-ci :http://bugs.python.org/issue3445)

Créer des models uniquement pour les tests

Ici après quelques test infructueux, je suis finalement tombé sur ce ticket dans le track django. Dont le dernier commentaire remonté à 2 mois. Et en fait, l’astuce est toute simple. Il suffit de créer le model de test dans le fichier de test qui va bien (c’est ici au niveau de mon code) et ensuite de modifier manuellement une des migrations django pour ajouter la création du modèle, uniquement si on est dans le mode Test. Petite modification de mon cru comparé au code donné dans le ticket, j’ai fait en sorte que les models de tests soit créé si la base commence par test ou si elle est stockée en mémoire (mon code est ici).

Rien de bien merveilleux ou de bien révolutionnaire, mais bon, on ne sait jamais, ça pourrait peut-être être utile à l’un d’entre vous.