Project

General

Profile

Anomalie #1798

Tentative de mise à jour d'une bdd alors que l'application est désactivée

Added by Joël Cuissinat over 8 years ago. Updated over 7 years ago.

Status:
Fermé
Priority:
Normal
Assigned To:
Category:
-
Start date:
05/23/2011
Due date:
% Done:

100%

Estimated time:
1.00 h
Spent time:
Distribution:
EOLE 2.3

Description

scribe_envole_gibii => non

root@amonecole:~# /usr/share/eole/update_databases.py
## Mise à jour de base de données ##
# Mise à jour de la base de données gibii53
 - Erreur : La base gibii53 n'existe pas

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"


Related issues

Related to Envole - Evolution #3569: Passer en revue les applis envole pour y ajouter le test d'activation Fermé 06/05/2012
Related to moodle - Anomalie #5878: Erreur update_databases.py à la première instance/reconfigure Fermé

Associated revisions

Revision 7ad22051 (diff)
Added by Bruno Boiget over 7 years ago

prise en compte d'un test pour les applications désactivées dans eolesql/collect_update.py (fixes #1798)

Revision 35883382 (diff)
Added by Bruno Boiget over 7 years ago

test_active dans la conf eole-mysql : désactive maj des bases si appli désactivée (ref #1798)

Revision 35883382 (diff)
Added by Bruno Boiget over 7 years ago

test_active dans la conf eole-mysql : désactive maj des bases si appli désactivée (ref #1798)

Revision 65c3be52 (diff)
Added by Amandine Manceau over 2 years ago

fix #1798 PHP Warning in the profile logs (#1800)

Revision f4e4df65 (diff)
Added by Amandine Manceau over 2 years ago

fix #1798 PHP Warning in the profile logs (#1800)

History

#1 Updated by Joël Cuissinat over 8 years ago

  • Target version changed from EOLE 2.3 Stable to Mises à jour 2.3 - 01 RC

#2 Updated by Benoit Vila over 8 years ago

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

#3 Updated by Emmanuel GARETTE over 8 years ago

  • Target version changed from Mises à jour 2.3 - 01 RC to Mises à jour 2.3 - 02 RC

#4 Updated by Joël Cuissinat about 8 years ago

  • Assigned To set to Bruno Boiget
  • Target version changed from Mises à jour 2.3 - 02 RC to Mises à jour 2.3 - 03 RC

#5 Updated by Joël Cuissinat almost 8 years ago

  • Target version changed from Mises à jour 2.3 - 03 RC to Mises à jour 2.3.4 RC
  • Distribution set to EOLE 2.3

#6 Updated by Daniel Dehennin over 7 years ago

  • Target version changed from Mises à jour 2.3.4 RC to Mises à jour 2.3.5 RC

jusque là ça passe

#7 Updated by Gérald Schwartzmann over 7 years ago

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

#8 Updated by Benjamin Bohard over 7 years ago

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.

#9 Updated by Bruno Boiget over 7 years ago

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.

#10 Updated by Bruno Boiget over 7 years ago

  • Status changed from Nouveau to Résolu
  • % Done changed from 0 to 100

#11 Updated by Bruno Boiget over 7 years ago

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'
                 )

#12 Updated by Daniel Dehennin over 7 years ago

  • Status changed from Résolu to Fermé

Avec le paquet eole-posh en version de dev 3.1.2-eole4~8.gbp13d5cd j’obtiens :

root@amonecole:~# /usr/share/eole/update_databases.py
## Mise à jour de base de données ##
Aucune base à mettre à jour

Also available in: Atom PDF