Distribution EOLE » Commun » eole-mysql

expected_response peut travailler en conjonction avec avec une requête SQL il faut donc que la base existe avant d'utiliser expected_response (et le script teste bien l’existence de la base avant d'utiliser expected_response) donc le test/l'erreur ne peut pas être évitée avec expected_response

il faudrait éventuellement rajouter un paramètre test similaire à celui de gen_database.py (sans remettre en cause "expected_response" qui reste utile)

en 2.2 le test de l'existence de la base est silencieux sur la console (log level 1 et 2 alors que l'affichage se fait a <= 0) en 2.3 le log level par defaut (0) est utilisé d'où l'affichage (cf #1643) ...

après, le cas n'est pas forcement fréquent non plus d'une applie installée mais jamais activée qui aurait une database (non crée donc) avec des updates

Joël Cuissinat a écrit :

scribe_envole_gibii => non

[...]

Malgré le test prévu dans /usr/share/eole/applications/updates/creole_gibii/config.py

Nb : c'est peut-être une incompréhension de ma part au sujet du paramètre : "expected_response"

reproduit avec un reconfigure :

lors d'une reconfigure un message d'erreur à propos des bases de données apparaît lorsque POSH n'est pas activé
Postconfiguration ***

génération des base de données ##

mise à jour de la base de données posh
    - erreur : la base de posh n'existe pas
    mise à jour de la base poshprofile
    - erreur : la base poshprofile n'existe pas

La liste des bases de données à mettre à jour est créée par la fonction load_apps_conf() (eolesql/collect_update). Cette fonction ne filtre pas les applications non activées.

Il n'y a pas vraiment moyen de définir automatiquement si une variable correspond à l'activation/désactivation d'une application.

Une solution pourrait être de fournir avec l'appli un fichier du genre /usr/share/eole/mysql/<appli>/variable_activation qui donne le nom de la variable à tester.

au final, j'ai mis en place la solution suivante:

dans config.py du répertoire update de l'application, on peut passer dans la structure une fonction qui teste l'activation de l'appli.

ça peut être la même fonction que celle qui est passée comme 'expected_response', mais elle ne prend pas de paramètre (expected_response peut recevoir ou pas le résultat d'une requête sql).

typiquement, ça sera une fonction dans ce style:

def test_activation():
    return test_var('activer_monappli')

par exemple dans eole-posh :

conf_dict = dict(db=DB,
                 expected_response=test_response,
                 test_active=test_response,
                 filenames=FILENAMES,
                 version='Mise à jour de posh'
                 )