La base de donnée de test ne supporte pas les Threads

Bonjour,

Suite à la discution sur l'indexation de la zep-12, on en avait conclu que ça serait bien de différé l'enregistrement des données pour la recherche et la publication.

J'était partis naturellement, sur l'idée de plusieurs Thread. Sauf que la base de donnée de test ("sqlite", in-memory) ne supporte pas les thread, c'est un souci connu de django et sqlite. Le code de Django à été adapté pour pouvoir faire fonctionner les threads et les bases de données de test mais seulement dans sa version 1.8.

Du coup, deux solutions:

• Y'a la solution proposé par artagis:

  asynchrone peut vouloir dire "on lance un tachecron" par exemple. Du coup la génération de l'index n'est pas synchrone à la publication.

• ou avant de lancer le thread, on teste si on en mode "test" et on lance la méthode sans le thread et on corrige ça quand Django 1.8 arrive.

Vous avez une idée d'une autre solution alternative ?

Je pense que la première est mieux car avec la deuxième est plus risquée (il y a plus de probabilité d'avoir un problème en production mais pas en local) !

Moi, j'aurais dit oui si on avais eu un Sentry fonctionnel: c'est déjà pas facile d'avoir des logs coté Django, alors des logs de chez cron, on est pas rendu :/

EDIT: je suis pas contre l'idée, mais j'aimerai savoir ce qui se passe de temps à autre, voir si on est dans le bon ou si on génère une erreur toute les heures, quoi.

Notons que munin peut tout à fait être trické pour trouver le nombre de message d'erreur. Ecrire un plugin qui compte le nombre d'erreur lancées par CRON dans syslog les 5 dernières minutes est très simple (même si ça reste un trick et de basse qualité et donc pas forcément souhaitable).

Notons d'ailleurs qu'il est tout à fait facile d'ajouter un fichier de log qui envoie les erreurs de génération pdf par email, mais on risque de tomber dans ce problème :

Bref, faut vraiment que l'assoc s'achète un second serveur là !

Sinon, je fais un simple logger en python. Quand il y'a une erreur, il écrira l'erreur dans le fichier d'erreur associé, récupéré par le Munin.

Heu, c'est pas vraiment le boulot de Munin hein.

C'est ce que j'ai dit spacefox, mais savoir le nombre d'erreur ça peut être fait à la marge.

Mais avoir un second serveur pour mettre munin + sentry + preprod ça ne serait pas trop.

@artragis: En fait, le serveur sentry est setup chez moi, à cette adresse: http://sentry.sandhose.fr

J'ai juste pas trop communiqué par rapport à ça, my bad ; suffit de vous inscrire, et j'ajouterais les personnes au projet.

@sandhose : Done. C'est pas grave que tu n'en ai pas dit plus.

Cool. Dans ce cas, j'imagine que cron appelant Django, on devrait voir les erreurs si elles arrivent

oui.

Dans ce cas, première possibilité. Comme dit Situphen, on va essayer d'éviter d'avoir un comportement trop différent en local et en prod (on a déjà assez d'ennuis comme ça avec Travis qui n'en fait qu'à sa tête).