search

GIP-GRADeS-BFC / SORMAS-Project

SORMAS (Surveillance, Outbreak Response Management and Analysis System) is an early warning and management system to fight the spread of infectious diseases.
https://sormas.org
GNU General Public License v3.0
0 stars 1 forks source link

Update sormas_schema.sql #30

Closed zinebIdl closed 4 years ago

zinebIdl commented 4 years ago

add update schema_version

GRADeS-Gwen commented 4 years ago

Je viens de tester le code sur le serveur : je ne vois plus l'erreur SQL, mais par contre j'ai toujours l'erreur suivante:

    at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:496)
    at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:442)
    at javax.naming.InitialContext.lookup(InitialContext.java:417)
    at javax.naming.InitialContext.lookup(InitialContext.java:417)
    at de.symeda.sormas.api.FacadeProvider.lookupEjbRemote(FacadeProvider.java:280)
    ... 66 more
Caused by: javax.naming.NameNotFoundException: ConfigFacade not found
    at com.sun.enterprise.naming.impl.TransientContext.doLookup(TransientContext.java:237)
    at com.sun.enterprise.naming.impl.TransientContext.lookup(TransientContext.java:204)
    at com.sun.enterprise.naming.impl.TransientContext.lookup(TransientContext.java:208)
    at com.sun.enterprise.naming.impl.TransientContext.lookup(TransientContext.java:208)
    at com.sun.enterprise.naming.impl.TransientContext.lookup(TransientContext.java:208)
    at com.sun.enterprise.naming.impl.SerialContextProviderImpl.lookup(SerialContextProviderImpl.java:70)
    at com.sun.enterprise.naming.impl.LocalSerialContextProviderImpl.lookup(LocalSerialContextProviderImpl.java:114)
    at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:483)
    ... 70 more

fichier de log : server.log

zinebIdl commented 4 years ago

Y'a toujours l'erreur concernant org.postgresql.util.PSQLException: ERROR: relation "action" already exists. Je pense qu'il essaie de recréer cet élément dans la base en relançant le sormas_schema.sql, il a dû être mal inséré.

zinebIdl commented 4 years ago

Je pense qu'il faut que la relation soit supprimé pour qu'elle soit bien inséré.

xavier-calland commented 4 years ago

@GRADeS-Gwen Y a-t-il eu dernièrement des scripts/commandes SQL exécutés manuellement sur le serveur ? Peux-tu indiquer le contenu de la table schema_version sur le serveur ?

zinebIdl commented 4 years ago

Je n'ai pas accès au serveur, mais je pense que lors de la merge lors de l'ajout de Actions de l'événement dans la page événement y a sûrement eu des modifications de base, il faut regarder de ce côté.

GRADeS-Gwen commented 4 years ago

Aucune modification manuelle n'a été faite. Voici le contenu de la table schema_version : schema_version.csv.gz

Si vous m'indiquez quelle relation serait à ssupprimer, je pourrais le faire avec une requête.

zinebIdl commented 4 years ago

Peux t-on supprimé la table action avec les clés et index associés ?

xavier-calland commented 4 years ago

La base actuelle n'est pas en bonne version, cela vient du merge de la branche de dev HZI il y a quelques semaines. Il y avait des

La PR https://github.com/GIP-GRADeS-BFC/SORMAS-Project/pull/21#issue-441291101 a corrigé le problème de conflit au niveau du script SQL. Il n'en reste pas moins que la base actuelle ne correspond pas aux versions attendues.

cf. commentaire dans la PR

Il est à noter qu'au démarrage de l'application, les patches (ensembles de commandes SQL avant la ligne INSERT INTO schema_version (…)) non enregistrés dans schema_version sont exécutés. Lors du déploiement de cette version sur le serveur de test, la migration du schéma de base de données ne pourra pas s'effectuer correctement. En effet, la version GRADeS précédente a enregistré les patchs 216 à 218, ils ont maintenant les numéros 218 à 220. Cela vient du fait que la version HZI a également défini les version 216 et 217. Il faudra donc corriger le schéma de la base de données et appliquer les scripts de migration manuellement (avec les bons numéros de version).

La base actuelle indique que les informations suivantes pour les scripts 216 à 218 :

version_number comment
216 Adds the field origin of the source of an event
217 Adds actions to events
218 Add field type of risk of an event

alors que ces scripts correspondent maintenant aux version 218 à 220.

@zinebIdl supprimer la table ne suffit pas, car Sormas voit la base de données en version 218, il pense donc que les scripts 216, 217 et 218 ont été passé mais ce n'est pas le cas.

Pour remettre la base en état il faut

1 - Modifier les version_number des scripts 216, 218 et 219

UPDATE schema_version SET version_number = version_number + 2 WHERE version_number = 218;
UPDATE schema_version SET version_number = version_number + 2 WHERE version_number = 217;
UPDATE schema_version SET version_number = version_number + 2 WHERE version_number = 216;

2 - Exécuter manuellement les scripts SQL 216 et 217

https://github.com/GIP-GRADeS-BFC/SORMAS-Project/blob/ca9b3c062a6cceb68765594ce4c7748e58397509/sormas-backend/src/main/resources/sql/sormas_schema.sql#L4625-L4670

zinebIdl commented 4 years ago

Je comprends le souci, par contre comme je n'ai pas accès à la base de dev, je ne peux lancer les scripts moi même.

GRADeS-Gwen commented 4 years ago

La correction au niveau des déploiements des scripts de base a fonctionné : schema_version(1).csv.gz

Et j'ai tenté un redéploiement derrière du code de ce PR est c'est passé.

Au vu des problèmes lié à la base, je vais intégrer à ma procédure de déploiement un backup de la base pre-deploiement.

Mais les merges des sources sormas nécessiterons à chaque fois un traitement particulier pour "augmenter" les révisions de nos scripts.